标签：software-delivery

为什么 Codex 应该是 worker，而不是 scheduler

解释为什么 Codex 等 AI coding 工具应该被约束为一次性 worker，而不是长期调度器或发布控制器。

说明 AI 执行任务时为什么需要受控上下文包：只给它该看的来源、规则和真相边界，而不是让它在全仓库里随机搜索。

说明 AI 交付不能只说已经完成，而必须附带可复核证据、验证结果、风险说明、人工决策入口和可追责路径。

说明 AI PR 为什么不能只交付代码，还必须附上测试结果、截图、日志、风险边界和可复核的证据包，而不是只看 diff。

说明如何把一次 AI 失败转化为项目记忆：更新规则、测试、检查清单和上下文包，让流水线持续变强，而不是停留在聊天纠错。

说明如何用 GitHub label、branch 和 comment 组成可审计的 AI 工程状态机。

说明 human-in-the-loop 不应只是最后确认，而应站在需求、风险、发布和回滚等关键边界上。

说明真实项目中 AI 不应直接修改主工作区，而应在隔离空间执行，并通过阶段门、证据和人工检查进入主线。

解释为什么 GitHub issue 应该成为 AI coding worker 的可执行合同，而不只是待办标题。

说明如何从私有生产经验中安全提炼公开方法论、模板和 toy example，而不是直接开源私有脚本。

解释为什么 PR merged 不等于 done，以及 AI 工程流程中 release boundary 应该如何保留。

很多人使用 AI 写代码时，会把整个流程放进一个聊天窗口：描述需求，让 AI 读仓库、改代码、跑测试、总结结果。

说明 AI 开发任务为什么要先从聊天需求转成任务合同，并根据成熟度、风险和证据要求选择执行模式，再进入写代码。

解释为什么 AI 修复任务需要 triage、analysis、implementation 和 evidence 等阶段门禁。