强模型能更快地写出代码，但复杂任务真正难的是：怎样定义完成、怎样在中断后恢复、怎样把实现交给下一位执行者，以及怎样避免模型在自我判断中提前宣布成功。Comet 的思路是把这些约束放到模型之外，用可检查的项目状态和运行时门禁管理整个变更过程。
问题与目标
单次对话里，模型可以完成大量实现工作；一旦任务跨越多个阶段、需要验收或可能被另一个会话接手，仅靠上下文记忆就容易出现三类问题：目标逐渐漂移、验证标准不明确，以及重启后无法可靠续接。
Comet 不试图替代模型写代码，而是把变更的形状、规格、验收条件和执行状态显式保存下来。模型仍负责实现，运行时负责判断是否完成，项目文件负责恢复现场。这种分工尤其适合影响长期行为、风险较高或需要多人/多智能体交接的改动。
两种运行模式
Classic：显式阶段推进
Classic 模式采用完整生命周期：
- Open：建立变更，明确范围、目标和不做什么。
- Design：形成设计与任务拆分，把模糊需求转成可执行工作。
- Build：按任务实施，同时持续记录状态。
- Verify：依据预先定义的验收条件检查结果。
- Archive：保存最终状态，为以后审计或复用提供依据。
如果只是小修复或轻量调整，可以选择更短的 hotfix/tweak 路径，避免为了形式完整而引入过重流程。关键不是所有任务都走相同步骤，而是让流程强度与风险匹配。
Native：把实现自由交给强模型
Native 模式减少对实现过程的细分，保留真正需要外部约束的部分：规格、验收、交接和恢复。执行模型可以自主决定如何修改代码，但最终结果要经过运行时检查和只读验证器。若验证失败，则进入有边界的修复循环，而不是无限自我反思或反复重写。
这种架构可以拆成几个职责：
- 规格层定义要交付的行为与边界；
- Builder handoff把当前目标、状态和约束交给实现模型；
- Runtime checks执行机器可检查的完成条件；
- 只读 verifier独立判断产物是否满足规格，避免验证阶段顺手修改结果；
- 有界修复循环限制失败后的重试范围与次数；
- 可携带状态与归档让任务可以跨会话恢复。
安装与首次检查
原帖的安装示例固定到 0.4.0-beta.17，并提示发帖时已经出现 beta.18。复现时应先决定是严格跟随示例，还是查看项目当前版本后再升级，不要在同一次试验里混用版本。
npm install -g @rpamis/comet@0.4.0-beta.17
comet init
comet doctor
comet status
init 用于初始化项目中的 Comet 状态，doctor 检查环境和配置是否完整，status 则确认当前变更所处阶段。原帖没有给出所有平台、Node.js 版本和权限要求；如果安装失败，应先核对项目文档及实际报错，不要把环境问题误判成工作流设计问题。
如何落地到真实项目
可以先从一个中等规模变更试用，而不是立即覆盖全部仓库：
- 选择一个会改变长期行为、但范围仍可控制的需求。
- 写清输入、输出、失败条件和明确不做的范围。
- 把可自动验证的条件转成测试、构建或静态检查。
- 让模型自主实现，但不允许它修改验收标准来适配自己的结果。
- 中断一次会话后重新进入，检查状态文件能否让新会话继续。
- 验证失败时只修复已定位的问题；达到重试边界后转人工判断。
验收重点不是生成了多少代码，而是任务能否被独立复核、失败能否定位、状态能否恢复。
适用边界与工程经验
个人的一次性小改动未必需要完整框架，直接使用更轻量的技能或检查清单可能更高效。团队协作、长周期重构、风险较高的发布以及需要跨模型交接的任务，才更能体现外部状态和独立验收的价值。
这套方法可复用的核心是三点：把完成条件写在实现之外；让验证者保持只读；为失败设置明确边界。模型能力越强，越应该把它用于实现与推理，而不是让同一个模型同时定义目标、修改产物并宣布自己通过。
原作者：luokakale（洛卡卡了）
原帖：https://linux.do/t/topic/2763093