做 dev_co 前，我让 AI 回看过去的对话、项目记录和几次不愉快的反馈，想弄清楚哪些反复出现的麻烦与我的协作方式有关。
我的想法经常在开发中变化：讨论到一半换了方案；换一个 Coding Agent，又担心它不知道当前目标，只能重新翻源码。Agent 忙了很久，我仍会追问：这一轮到底做成了什么？为什么一个小改动带出了这么多步骤？
这些问题不能全算到使用者头上。模型仍然应该核实事实、尊重授权、如实报告结果。但我也需要说清楚，一句话是想法、决定，还是对上一轮结果的纠正。否则，即使它很积极地执行，也可能在认真完成一个我已经不想要的目标。
后来，我和 AI 一起把这些问题整理成了 dev_co，让 Codex 和 Claude Code 共用，采用 MIT 许可证开源。
这套技能带有明显的个人取舍，主要供刚开始用 AI 开发完整软件或系统、又遇到类似问题的人参考。它不替所有开发者规定流程，只整理三个问题：讨论里的决定怎样进入项目，项目的状态怎样被接手，完成声明又该由什么证据支撑。
改主意时，要明确哪些旧决定失效
讨论这个技能时，我直接说过：
我常常在做的过程中改变想法，agent最后都不知道哪个是现在的真实想法了。
改主意本身没有什么错。看过原型才发现操作不顺，试过数据才发现原先的方案不现实，这些都是开发的一部分。麻烦在于，想法变化后，旧要求和新要求可能同时留在上下文里。
假设一个自用工具原本准备接实时数据，后来决定先做离线导入。接着我又说：“以后能不能加个 AI 评分？”这几句话的地位并不一样。离线导入可能是已经生效的决定，实时接入应当暂缓，AI 评分还只是候选。如果 Agent 把它们都当成需求，任务就会不断膨胀。
因此，dev_co 要求记录决定的状态：有效、候选、已替代。明确改向时，修改当前目标，把冲突的旧决定标出来，保留其他仍然有效的要求。不能只在旧计划最后追加一句新想法，让两套方向继续并列生效。
这里还有一个容易忽略的区别：最新消息不一定替换全部旧要求。我说“先改成离线”，并没有自动撤销“保留原始备注”“不要改变返回字段”等约束。只按消息时间决定优先级，仍然会丢东西。需要判断的是，这次变化究竟影响了哪项决定。
我自己也得学会表达这种变化。“这轮改成离线，实时接入先放下，评分只是候选”，就比连续抛出几个点子更清楚。哪怕最后由 Agent 帮我整理，我也应该检查它有没有把一句设想升格成正式任务。
我最需要改的是：提出新方向时，同时交代它与旧方向的关系。
项目记录不能混淆意图、实现和证据
我很在意换 Agent 时的接手成本。项目没有好用的记录，新的 Agent 就要重新判断我们做到了哪里。我觉得慢，它却可能连从哪个文件看起都不知道。
但“记忆越多越好”也容易出问题。旧计划、会话摘要、自动记忆、交接文件各有一份，谁来告诉下一个 Agent 哪份仍然有效？一份刚生成的摘要，也可能只是把已经过时的目标重新抄了一遍。
我们的选择是保留一份当前记录，优先复用项目原有文档或任务系统。持续开发确实需要、项目又没有时，再补 docs/CURRENT.md。重要决定发生变化时更新它，摘要放在开头，长历史通过链接追溯。
不过，一份当前记录不意味着所有事实都由这个文件说了算。接手时需要区分几类问题：
| 想确认什么 | 主要依据 |
|---|---|
| 现在准备做什么，哪些决定仍然有效 | 当前明确指令，以及核对过的项目记录 |
| 代码实际上实现了什么 | 当前工作树、相关源码和实际运行行为 |
| 某项行为是否已经验证 | 对应版本、输入、环境与范围的检查证据 |
| 当时为什么这样选择 | 有来源和适用范围的历史决定 |
这几类依据不能互相代替。文档里写了“已经完成”，不代表当前代码就正确；测试通过，也不能反过来证明产品方向符合我现在的想法。发现冲突时，应该沿相关文件和证据核实，不能简单选择时间最新的那一份。
当前记录因此更像接手入口：这一轮的目标是什么，关键模块在哪里，最近检查了哪些行为，还有什么没确认，下一步准备做什么。它不需要复制大段源码。代码仍要读，只是可以带着问题、沿着导航去读。
Codex 和 Claude Code 共用的也是这些信息。它们各用自己的工具和权限，但核心约定与项目当前记录保持一致。宿主自己的自动记忆仍有独立的加载和写入机制；共享这份记录，并不等于技能接管了所有记忆。
对我来说，这个取舍比多保存几份聊天摘要更重要。我需要的是下次能接着做，而不是把每次对话都完整存档。
每轮开发都要留下可检查的结果
让 AI 执行任务很方便，也让我更容易追加要求。一个功能还没走通，旁边又冒出另一个值得做的功能。文件越来越多，真正能试用的部分却可能还很少。
所以 dev_co 要求先选定本轮的可观察结果。它可以很小，但应该覆盖必要的环节。比如，修好一次导入后，数据能按原字段返回，备注保留，失败情况有明确反馈。这样我可以检查它是否满足要求，而不是只看到某个底层模块已经写好。
小步推进也不能机械地理解为每次只改一个文件。一个结果需要跨几个模块，就把必要的部分一起做好；反过来，只改一句文案，也没必要重新讨论架构和立项。步骤的大小应该围绕这次结果来判断。
我希望 Agent 能自主推进，先查那些从代码和文档就能找到答案的问题，沿用已经确认的要求和授权。只有真正影响产品方向、成本、权限或难以撤回的取舍，才需要我补充决定。反复让我批准同一个要求，并不能增加多少确定性。
同样，我给反馈也需要更具体。“导入后 000001 变成了 1”，能引出复现和排查；“怎么又不行”，只表达了我的不满。我发火的时候，尤其需要补上实际行为与预期之间的差别。Agent 则应该先找原因，不因为收到一次批评就扩大成一轮全面重构。
连续尝试没有新证据时，也要停下来换判断。下一次准备排除什么原因，最便宜的检查是什么，已经失败的路线为什么不再重复，都应该能说清楚。批量或付费执行先试代表性样本，再按已同意的范围扩大。
个人项目的完成条件也据此收敛。我通常自己开发，PR 不必成为每次交付的固定环节。约定结果做到了，适用验证完成了，必要的记录更新了，就可以交付这一轮；提交、推送、发布仍按实际授权处理。
测试范围要有理由，旧证据不能一直复用
我曾经问：每次只改一个小模块，都跑全量端到端回归，是不是很浪费时间？
这句话背后还有另一个问题：如果不跑全量，到底凭什么判断这轮足够了？“少测一点”本身算不上规则。
我们的做法是先看改变了什么行为。局部逻辑修复，从复现和相关测试开始；改了接口、持久化或共享行为，就补相应的契约与集成检查；准备发布，再按项目要求检查核心路径。验证过程中发现影响比预期大，就扩大范围。项目本来要求的检查，不能因为技能强调小步推进而被悄悄省略。
Agent 需要说明，为什么选择这些检查，以及哪些结论尚未获得支持。本地样例通过，不证明真实数据源可用；真实接口能调用，也不证明整个用户流程满足需要。代码写完、本地验证、真实服务检查、部署、用户认可效果，是不同的状态。
证据还会过期。假如某个版本检查通过，随后相关源码、依赖或验收目标变了，原来的通过记录就不能直接借给新版本使用。报告里只有一句“测试已通过”，后来的 Agent 很难判断它究竟对应什么。
这也是辅助脚本存在的理由。verify 执行事先声明的检查，记录结果与相关输入；gate 核对这些证据是否缺失、失败或发生变化。它只检查声明的范围，不会替 Agent 推导完整依赖图。漏掉了关键输入，得到的判断就可能过强。
我们也讨论过 TDD、SDD。行为清楚、失败能复现时，先写一个会失败的测试很合适；需求和接口还含糊时，先写清行为、边界和验收，采用 SDD 中先明确规格的做法。这里的规格也必须反映当前决定，否则只是把旧需求写得更正式。
我不准备把这些方法变成所有任务都要走的固定程序。布局不确定，可以先看原型；数据是否拿得到，可以先试数据；局部 bug 有明确症状，就先复现。选择方法，是为了减少眼下的不确定性。
新技能解决不了规则冲突
做 dev_co 时，我还担心一个问题：其他技能能自动触发，它却要我每次主动喊，会不会反而更难用？
这不能只靠把技能描述写得更积极来解决。Agent 同时还会看到全局规则、项目入口、其他技能和历史上下文。如果一份规则要求小改直接做，另一份流程却默认展开完整规划和回归，单独加一个新技能，并不会让冲突消失。
因此，我们先梳理了我本机的全局 AGENTS.md、CLAUDE.md 及冲突的附加规则，再让两个宿主共用 dev_co 的核心。专项技能仍然可以用，但要沿用已经接受的要求、接口和验证重点，不能一加载就重新启动一整套流程。
在我的使用习惯里，lfg、review、qa 这类具名流程只在我明确选择时进入。普通地说“检查一下”或“修一下”，不等于我选了那个完整技能。这不妨碍 Agent 做当前任务必要的审查和测试。
开源安装与我的本机配置也需要区分。把 dev_co 放进技能目录，不会顺便改掉你已有技能的自动调用设置。README 提供了可选的全局路由约定，已有规则冲突仍要单独处理。技能本身也不能改变宿主的指令优先级和权限。
我不想每次都手动提醒，但也不愿用一个触发范围更大的技能去压住其他技能。入口需要协调，规则需要保持一致，这部分无法靠名字解决。
不该触发 dev_co 的场景
入口补好后，我发现连独立评测也在用 dev_co。我又提出，范围是不是太大了？
这是一次很有用的反例。我们原本想让持续开发更容易进入，结果“项目里有代码”成了过于宽泛的暗示。一个仓库里既可能在开发评测平台，也可能只是运行现成脚本、比较一次结果。这两种任务需要的过程并不相同。
现在按本轮意图判断：持续功能开发、复杂修复、开发接手，以及准备构建的软件或系统规划，适合进入 dev_co。开发或改造评测系统也算开发；独立跑评测、分析结果、写报告、一次性脚本和孤立小改，直接处理当前任务。
仓库位置、已有当前记录、过去使用过技能，都不能单独成为触发理由。用户也可以明确退出或选择其他主流程。合理的自动调用，需要包含退出条件。
上下文的使用也有类似取舍。讨论越多，技能越容易厚。如果把研究、架构、原型、交接、验证和发布的全部细节每次都读进去，流程本身就会占掉很多注意力。
因此，日常入口只保留核心约定，详细资料按当前问题展开。项目记忆先看当前摘要，追溯具体决定时再读历史。只把一个长文件拆成多个文件，并不会自动减少读取量；还得明确什么时候读取、什么时候到这里就够了。
精简也出过偏差。早期“讨论可以只读核心”的表述太宽，一次新项目试用跳过了必要的问题定义指南。后来收紧为：用途和第一版范围尚未明确时，先处理这些问题。“只讨论”限制的是修改文件，必要的理解工作仍然要做。
这个例子提醒我，两边都需要检验。加载得太多会拖慢，省略得太多也会漏掉真正影响方向的问题。文件短了、步骤少了，都不是效果已经变好的证据。
哪些可以自动核对，哪些仍要人工判断
我问过，只有 prompt 和 skill，Agent 会严格执行吗？目前的答案仍然是：不能保证。
在这个项目里，我把约定和检查分开看。技能告诉 Agent 怎样组织工作；项目记录保存当前决定和接手入口；脚本核对能够明确表达的证据关系。需要自动提醒时，再选择接入宿主 Hook。
例如，brief 可以生成有长度上限的摘要，init 可以在确有需要、且记录不存在时初始化它。verify 和 gate 能处理已声明检查的执行与证据核对。新检查失败或异常退出，不能继续把上一轮的通过状态当作本轮结果。
这些办法能让一部分遗漏更容易被发现，却不能证明需求合理、测试充分，或用户已经满意。Hook 也只覆盖配置选中的入口。项目文件和脚本本身可以被编辑，不能把它们说成不可绕过的强制边界。
权限和付费上限需要由宿主或外部受控系统承担。脚本里的 cost: local 只是声明，不会因此隔离网络。安装技能也不会自动启用 Hook；生成配置、宿主载入、实际触发，需要分别验证。
这种区分对新手尤其有用。一个地方写了“必须”，只能说明有这条要求；一个程序返回成功，也只能支持它实际检查过的内容。知道这两者的边界，才不容易把流程存在误认为风险已经消失。
下一轮怎么继续验证
这一版有 43 项脚本行为测试通过，覆盖证据失效、失败与中断、进程清理、路径边界和 Hook 事件适配。触发范围收窄后，也用隔离素材做了五次真实 CLI 场景试用，包括独立评测不加载、持续开发接手加载，以及评测工具开发规划保持只读。
这些试用有具体环境和样本范围。它们能说明本机这些新会话里的行为，不能推到所有模型、所有项目，更不能证明长期开发一定更快。Hook 的协议测试也不等于真实宿主集成已经验证。早期漏读指南的反例，就说明需要观察实际行为，不能只检查规则写得是否完整。
我接下来想做一个 A 股相关的自用工具，准备拿它继续试。现在还不能说 dev_co 已经改善了这个项目的长期效果。
我会看一些很具体的变化：改向以后，旧要求还会不会被继续实现；换一个 Agent，是否能沿记录找到接手点；本轮结束时，我能不能检查到一个结果；测试范围有没有理由；发现问题时，能不能找到对应版本和证据。
如果你刚开始把 AI 用于持续开发，也经常边聊边扩需求、换 Agent 后重新介绍项目、分不清“写好了”和“可以用了”，可以从一个真实的小任务试起。这里的“新手”指协作习惯还没形成的人，不一定是完全不会写代码的人。有成熟项目流程时，先沿用原流程，选取适合的约定即可。
README 有安装说明。Codex 用 $dev_co，Claude Code 用 /dev_co。第一次不用把整个项目重新规划一遍，可以只让它恢复当前目标，处理一个明确问题，解释验证范围，再更新原有记录。
而我自己至少要做两件事：改变想法时说清替换关系，反馈结果时指出具体差异。这两件事如果一直含糊，再长的技能也只是在帮 Agent 猜。下一次开发结束后，我希望能回到项目记录里，检查这些习惯有没有真的发生变化。