我做了一个月真实项目后，越来越确定 AI coding 真正难的，不是让它更自动化，而是让它在项目里变得可控、可复用、可交接。codex-workflow-kit 就是我基于这套判断整理出来的一版工作流模板。
刚刚过去的3月份，我一直在项目里持续用 Codex 进行 AI 编程。
我已经不太关心提示词了，现在决定 AI coding 能不能真正进入项目的，是另外几件事：
-
这轮任务的上下文有没有先收好
-
哪些地方能改，哪些地方不能碰
-
高风险链路开始之前，有没有先做边界检查
-
做完之后，下一轮能不能顺着接上
也就是说，AI coding 一旦真正进入项目，问题很快就会从“怎么和模型说话”，变成“怎么让它按一种稳定的方式开工、推进和收尾”。
所以，我做了一个开源的工作流模板库 codex-workflow-kit，本质上就是在补这一层。
仓库地址先放这里：github.com/lmmzzh/code…
这篇文章我不是要写项目介绍，我是想讲清楚，这一个月里我为什么越来越不相信“更多自动化”这条路：
真正让 AI coding 进入项目的，不是更多自动化，而是更稳定的工作流边界。
真正进入项目以后，问题很快就不再是“它到底会不会写”
如果只是做 demo，或者在一个很干净的小仓库里试一段功能，大家关心的当然还是“它到底会不会写”。
但真到项目里，长期同时存在的往往是这些东西：
-
已经在线跑着的旧链路
-
不能顺手扩改的模块边界
-
一轮接一轮的 handoff
-
还在变化的产品口径
-
需要真机、截图、回归去确认的结果
-
看起来只改一个点，实际上很容易带偏整条流程的高风险区域
这时候，最容易出问题的地方，通常已经不是“模型不会写”，而是“它很容易以错误的方式开始工作”。
而且这种问题，很多时候还不能一眼就能看出来，反而是你做过项目之后才会察觉到的小问题：
-
你本来只想继续昨天那轮改动，它却又从头理解了一遍
-
你只是想先确认边界，它已经直接开始实现功能了
-
你只是想改一个页面，它顺手把相关的几个模块也一起改了
-
你只是想修一个局部问题，它开始往更大的重构方向发散
-
你做完了一轮代码实现，下次再回来时，又得重新解释一遍需求是什么
所以到后面，我越来越确定一件事：
AI coding 真进项目以后，真正的主战场已经变成了上下文组织、边界控制、默认动作和交接能力。
我沉淀下来的，不是更多技巧，而是一个更小的结构
我经过一个月的真实项目业务开发之后沉淀下来的，是一个很小的结构：
-
入口文件
-
memory
-
少量高价值 skill
入口文件其实很好理解。
对 Codex 来说是 AGENTS.md，对 Claude Code 来说是 CLAUDE.md。
它们做的不是替模型写功能，而是先把这个项目最基本的工作方式挂上去。
比如：
-
中大型任务先分析再动代码
-
高风险链路别直接下手
-
改动范围不要顺手扩大
-
一轮做完以后要有 handoff
这些东西不是这轮任务的细节，而是我希望 AI agent 长期遵守的“规章制度”。
这类内容，我后来基本都放进 memory。
原因也很简单，它们不是一次性信息，而是项目长期有效的工作规则，每次都重新讲一遍，不现实，硬塞进单次任务描述里，也不稳定。
剩下那些高频、重复、边界清楚的动作，我才把它们沉淀成 skill。
这一步很关键，因为很多人一开始做 skill，最容易犯的错就是：什么都想技能化。
最后看起来像是能力更多了，实际结果往往是：
-
skill 越来越多
-
触发边界越来越重叠
-
自动命中反而更乱
-
真正高频的那几个默认动作反而不清楚
所以我最后的判断不是“经验越多越该做成 skill”，而是：
长期规则留在 memory，只有稳定、重复、边界清楚的工作流，才值得变成 skill。
为什么我第一版工作流模板库只保留了 3 个默认 skill
第一版真正留下来的默认 skill，只有 3 个：
-
current-task-capsule -
high-risk-preflight -
handoff-retrospective
这 3 个不是我拍脑袋挑选的。
它们正好对应了项目里最容易反复耗时间的 3 个环节：
-
开工前
-
动手前
-
收尾后
1. current-task-capsule
这个 skill 解决的不是“怎么实现”，而是“这一轮到底要做什么”。
只要任务一大、上下文一多，或者刚从前一轮 handoff 接过来，最容易出问题的通常就不是技术细节，而是开工前的任务边界没收住。
比如：
-
这轮代码修改的目标是什么
-
明确不改什么
-
先看哪几个文档
-
主要代码落点在哪
-
验收标准是什么
如果这些东西不先确定好，后面的实现很容易一开始就跑偏了。
所以这个 skill 的价值，不在于它有多聪明，而在于它能先把“开始工作”这件事稳定下来。
2. high-risk-preflight
这个 skill 对我来说更重要，因为项目里总有一些地方，不能在没看清边界的时候就直接碰。
它们不一定每次都不能改，但你至少得先回答这些问题：
-
这轮到底在改什么
-
项目中哪些旧代码的逻辑必须保持不变
-
最小风险的方案是什么
-
哪些路径要回归、验证
如果这些问题还没回答清楚，就直接下手写，很容易把一次局部修补做成一次无意改写。
我自己总结，很多高风险返工，本质上不是“实现能力不够”，而是“开始实现之前，没有先停下来做一次边界预检”。
所以 high-risk-preflight 对我来说不是附加动作，而是某些场景下的默认门槛。
3. handoff-retrospective
很多人会把 AI coding 理解成“帮我写代码”。
但只要用AI结合真实项目实践过一段时间，你就会发现，最能持续节省时间的，往往不是“帮我用代码快速实现出某些功能”，而是“下一轮的代码实现或者修改时，AI可以自动按照我的规范来做事”。
如果每次做完都没把这轮到底改了什么交代清楚，下一次回来还是要重新理解：
-
上一轮到底改了什么
-
哪些没动
-
哪些还没验证
-
风险还在哪
-
下一次应该从哪里接着看
所以我现在很确定一件事：真正有效的 skill，不一定是看起来最厉害的那个。
很多时候，最有价值的反而是那些把“开始、边界、收尾”固定下来的默认动作。
专项 skill 可以有，但不要一上来就追求全自动
后来我也补过一些专项 skill，比如：
-
先把英文基线定下来，再逐步补齐其他语言
-
先把这批页面按类型分组，再决定实现顺序。
这些当然有价值，但我没有一开始就把它们放进默认层，原因很现实，专项任务天生更依赖场景，你如果过早追求“让它们都自动触发”，到最后，提速没提起来，倒是多了不少干扰和返工。
所以我后面给自己定的规则是：
-
默认 skill 只保留极少数高频动作
-
专项 skill 先按需点名调用
-
先看真实任务里是否反复出现，再决定要不要往默认层靠
这件事听起来保守，但对项目更重要，因为比起“功能看起来很多”，我更在意的是：
这套工作流是不是足够稳定，能让我明天正常使用，下周继续正常使用，下个月依然可以正常使用。
写出 skill 不算结束，真正重要的是验证和维护
这也是我后来很在意的一层。 很多 skill 仓库最大的问题，不是 skill 写得不好，而是它们停在“已经写出来”这一步就结束了。
但真到项目里，skill 真正要回答的是：
-
它会不会在真实的任务里真的触发
-
触发以后是不是方向真的对
-
有没有减少重复解释
-
会不会和别的 skill 重叠
-
会不会越加越多，最后把默认工作流冲散
所以后来我专门补了两层东西：
-
自动触发验证清单
-
skill 维护规则
前者解决的是“这个 skill 到底有没有实际收益”，后者解决的是“这套 skill 系统会不会自己失控”。
这两层一补上，整个仓库的味道就不一样了，它不再只是一个模板集合，也不只是一个 prompt 仓库，它更像一套能落到日常项目里的协作方式。
我最后把这套东西整理成了一个开源仓库
等这套结构在项目里跑顺以后，我没有继续往里面堆更多内容，而是先把第一版整理出来，做成了一个开源仓库：codex-workflow-kit
里面保留的是第一版最核心的东西：
-
AGENTS.md -
CLAUDE.md -
memory 模板
-
3 个默认 skill
-
2 个专项 skill
-
接入说明
-
自动触发验证清单
-
skill 维护规则
-
脱敏说明
-
iOS / Flutter 示例项目壳
我没有把它包装成 agent runtime，也没有把它做成“下一代全自动平台”。
我更想保留它最初长出来的样子：
一套来自真实项目实践的、本地化的、有边界的 AI coding workflow kit。
这套东西更适合谁
如果你也在项目里用 Codex 或 Claude Code，而且你在意这些事情：
-
改动边界
-
可维护性
-
交接成本
-
高风险链路别乱碰
-
默认动作能不能稳定复用
那这套东西大概率适合你。
如果你想要的是：
-
一键全自动 agent
-
benchmark 跑分项目
-
一套仓库直接替代模型或 runtime
那这套东西应该不是你的第一优先级。
因为它从一开始就不是冲着“最大自动化”的。
这一个月下来，我对 AI coding 的判断已经很不一样了
如果只看表面，很容易把 AI coding 理解成：
-
模型更强一点
-
工具更多一点
-
skill 更多一点
-
自动化更彻底一点
但这一个月我最大的感受是，真正难的是怎么让它在真实工程里变得：
-
可控
-
可复用
-
可交接
你可以把这理解成保守，也可以把这理解成慢，但至少对真实项目来说，这比“更像一个无所不能的 agent”更有实际价值。
这个仓库不是终点，我只是先把这套做法整理出来，让各位同行朋友们可以拿到自己的项目中进行实践使用。
