原来乱在哪里
我先不解释“项目管理系统”这个词。请看一台真实的电脑：系统会重装，今天装了一个 AI 工具，明天换了模型，后天又让另一个 Agent 来接手。软件可能装在用户目录，模型在另一块盘，密码在安全存储，测试结果在聊天里。你问“现在到底能不能用”，每个人都可能给出不同答案：有人看到程序图标，有人看到服务启动，有人真的生成过图片。这就是我们做启明时想解决的混乱。它不负责把所有东西塞进一个表格，而是让下一位接手的人找到同一条事实链。
我以前的总管理目录盘点过数百个资产条目，里面有目录容器、资料、模型、安装包、备份、临时产物和真正的项目。数百条目不等于数百个需要长期维护的项目，更不等于要写数百份会员档案。那个模板曾把分散资料按多个根目录梳理，记录旧路径与新路径的映射、迁移验证和回滚。它教会我们一件事：先识别原件、容器、入口和副本，再决定哪一个对象需要身份。分类视图只是找原件的入口，软链接也不是备份。
启明做了什么
我和我的 Agent Dark源最早用自己的管理模板整理项目、目录、设备和工具。后来发现，模板本身还不够：每个项目都得知道自己的边界，开新会话得先读关键上下文，长期对象得有稳定身份，结果得分清“登记了”“做了”“验证了”。这些做法从真实工作里逐步沉淀成启明 Skill。启明也取启明星的意思：不保证你永远不乱，但在下一次开始时给你一个能找到方向的入口。
启明把这个经验用在新项目上。第一次接入时，先问“这个目录到底负责什么”，再看有限范围的现有文件和规则。一个被引用十次的说明书也许只是某个会员的附件；一个只有五十行、但每周运行并需要升级的发布脚本，反而可能值得独立入会。文件大小、后缀和所在目录都不能直接决定身份。判断标准是：用户是否持有或明确接管它，它是否有独立用途、入口、维护责任和持续周期。
一个对象只保留一份权威档案。长期服务换了安装路径，更新入口，不要造一个“新服务”；某个 Agent 在自己的工作目录需要调用它，写引用，不要复制另一份服务状态。否则项目看起来记录更多，实际出现两个互相矛盾的答案。启明建立的关系是导航和责任线索：谁属于谁、从哪个任务长出、依赖什么、证据在哪里。它不是让你为每个 PNG、每行代码和每次聊天发会员证。
第一步，确定边界。你要对 Agent 说清“今天管理的是哪个目录”。启明先找这个项目是否已有 .qiming/workspace.json 或用户指定的管理入口，核对工作区身份、项目根和独立子项目边界。安装公共种子不等于自动接入所有目录；在本机项目里有权检查某个服务，也不等于在该服务源码目录启用同一个启明实例。这一步看似啰嗦，实际能阻止最危险的混淆：把历史归档当当前项目，把另一个客户的规则带进来。
第二步，区分现场与历史。Agent 对有限范围做只读观察：已有文档、源码、脚本、输出、账号引用、项目指令、Git 状态。它要说明“我实际读过这些”“这些没权限或没时间核对”“这个状态是某时刻观察”。发现旧 README 说服务已启动，而当前进程不存在，就记录冲突，不替任何一边编造解释。新项目可以从空文件夹开始；老项目优先保留已经能用的目录和命名。
第三步，建立一张短地图。接入后的 .qiming/START.md 只回答四件事：这是哪里，当前在做什么，相关事实从哪里读，下一步先做什么。稳定的约定放 .qiming/conventions.md；项目自己的 qiming-user/SKILL.md 告诉 Agent 如何在这里工作；宿主项目指令把最关键的范围和入口带到新会话。详细历史不塞满启动上下文，遇到具体任务再读对应会员、工作记录、原始资料和证据。这叫预加载关键上下文，不叫把知识库一次性灌给模型。
第四步，把眼前工作写成可验收的任务。目标不能只写“把 AI 管好”，要写“让这个模型在这台机器上完成一次文生图和图片编辑，保留输入输出与失败边界”。每个结果要有观察方法：文件哈希、服务状态、真实生成、用户浏览器操作、客户签收，按工作需要选。任务可以正在做、部分完成或受阻；完成状态与证据范围分别记录。文件存在不是功能通过，HTTP 200 也不是用户体验完成。
第五步，决定长期对象归属。先查有没有同一个会员；已有对象更新档案。新对象只有在用户持续维护、能单独接续时才给稳定 ID。内部辅助脚本归父会员，临时输出归任务证据，第三方 API 先记外部依赖。后来某个小脚本被多个任务反复调用、需要单独版本和维护人，再从附属产物提升为子会员，来源任务仍能回查。
第六步，留下可以接力的收尾。一次工作结束时，Agent 不该只说“搞定了”。它应指向实际产物，写明哪些验收通过、哪些没跑、哪条经验值得复用、下一次从哪里继续。若发生中断，保留最后已证实的一步和冲突状态，而不是为了显示完成把未知改成成功。项目短入口随当前任务更新；下次换会话时，新的 Agent 先读短入口，再按需往下走。这六步没有要求你先整理完人生，只要求今天这一件事变得可继续。
留下了什么
做完一次工作，目录里至少应有四个能找到彼此的入口：说明今天从哪里继续的短地图、描述长期对象的会员档案、写明目标与产物的任务、记录来源和适用范围的证据。知识与反复使用的工具按需要再沉淀，不为了填满模板预建空目录。
你可以把启明想成一种“给长期工作建立可接续关系”的方法，而不是有限行业名单。一个软件项目可以管理源码仓库、版本、发布脚本、缺陷、环境和客户验收。一个写作项目可以管理作品、采访素材、引用来源、修订决定和发布状态。一个网站可以管理栏目、内容日程、域名、统计口径、线上版本和用户反馈。一台电脑可以管理设备、系统配置、备份、恢复、长期工具和本地 AI。一个研究项目可以管理问题、候选来源、已取得原件、哈希、可支持的结论与仍缺的证据。
扩展从实际问题开始。某个模型每天都要手工跑同样的健康检查，先把检查步骤写清；重复而稳定后做一个只读脚本；脚本需要由不同 Agent 以固定参数调用，评估做成 MCP；某类决策需要 Agent 在特定任务下阅读规则，做成 Skill。每次扩展都要回答归属：它是哪个会员的内部工具，还是有独立调用者、版本、维护周期的子会员？还能回答来源：它是为了解决哪次任务的什么痛点？前面的 Pi 子会员是先有明确的视频工作流需求，才有项目 Skill 和维护档案；不是先建一个“Agent 集团”再找事给它做。
所以我给启明的要求很朴素：每次工作结束，能从短入口找到目标；能从任务找到真实产物；能从会员找到维护责任；能从结论找到验证；能从未知找到下一步。做到这些，一个混乱的人也可以从今天的一个目录开始，慢慢拥有自己的工作系统。这套系统不是替人思考，而是让人和 Agent 下一次思考时，不必从零开始。
验证到哪里
若这件事会持续几周或几年，资料在目录里，后面还会有新的 Agent、人或电脑来接手，启明很适合。若你需要知道项目当前目标、长期对象、证据边界和下一步，它也适合。即便现在只有一个空目录和一个想法，只要你准备从一个真实任务开始，它也能帮你建立最小入口。你不需要先成为条理分明的人。
若只是翻译一句话、查一个文件、问一个常识、做一张一次性图片，直接做完通常更快。若你想要“一键安装后自动控制所有目录与账号”，启明不做这种默认接管。若你想用一份任务卡代替数据库备份、生产监控、客户签字或专业判断，它也帮不了你。启明最擅长保存工作关系和事实边界，最不该做的是假装自己已经验证了没有发生的事情。
还有一个需要先停下的情况：你无法确定当前目录里的哪些资料属于你、哪些是他人私有、哪些凭据可被 Agent 读取。此时先划定范围。账户卡只保留密码库或系统钥匙串的引用；密钥值不要写进普通 Markdown、JSON、Git 仓库或公开案例。接入一个客户项目也不代表有权公开客户名称、内部地址和真实数据。本文展示的是经过摘取与脱敏的管理方法，不是把原项目完整搬到官网。
下面的系列文章把同一方法放到本机 AI、Agent 子会员、客户交付、硬件研究、网络运营和官网发布中。案例均作脱敏处理；一次本地测试、目录里有文件、网页能打开，都只支持各自范围内的结论。
启明目前有 Codex 的定向验证，也收到一份 OpenCode 现场报告；完整的跨 Agent、跨系统行为矩阵仍未完成。每个项目还要在自己的宿主、目录和实际任务里验证接续与写入，不能把“认识 Skill 文件”直接当成“管理过程可靠”。