你上周大概让 AI 干过这些事：
把 bug 报告转成可分配的任务单。
审查一段代码。
把三个不同来源的信息合并成一份摘要。
发东西之前先检查一遍。
给一堆客户消息排优先级。
从几个数据源拉数字，看看哪些有变化。
第一次，完全正常。
第二次，也还行。
到第三次你还在复制粘贴同样的提示词时，这个任务就已经有规律了。
有规律，就意味着你可以留下一个工具。
这个工具不必很庞大。它可以是一个测试运行脚本、一个 deploy-preflight.md、一个 triage-checklist.md、一个 SKILL.md、AGENTS.md 里的一条新规则，或者一个每天跑一次的指标检查清单。
关键是，下次同样的工作出现时，Claude Code/Codex 不用再猜你的标准。
它应该直接从你的项目里读取：
这个任务从哪开始。
输入是什么。
好的输出长什么样。
哪个文件是事实来源。
哪些它可以自动做。
哪些地方必须停下来等人类决策。
一次性的对话不会产生复利
很多人把 Claude Code/Codex 当成一个高级聊天窗口来用。
今天：
把这个 bug 报告转成可分配的任务单。
明天：
比较这三个选项，告诉我哪个风险最小。
后天：
拉这周的数据，标记所有下降的指标。
每次都能帮你省点时间。
但每次你都得重新解释标准。
任务单需要复现步骤和优先级。
比较需要清晰的权衡利弊。
指标需要和上周对比，而不是只看原始数字。
本地通过不代表可以安全发布。
任何面向公众的内容，在人类批准前必须停下。
这就是重复自己的代价。
更好的做法：每次任务完成后，在项目文件夹里留下点东西，让下次更轻松。
今天处理一个 bug，留下一个 triage 检查清单。
今天比较选项，留下一个决策模板。
今天拉指标，留下一个每周指标脚本。
今天发现 AI 越界了，把那个审批关卡写进 AGENTS.md。
每次任务后，项目都应该多知道一点东西。
先定义结果，再定义步骤
我不会从写这个开始：
1. 收集信息
2. 做决策
3. 输出结果这太模糊了。AI 读了还是得猜你到底想要什么。
更好的起点是描述“完成”长什么样。
假设你想让它给 bug 排优先级。别只说“告诉我哪些 bug 重要。”
像这样写：
目标：
确定这个 bug 报告的优先级。
输入：
- Bug 描述和复现步骤
- 影响范围（多少用户 / 哪个功能）
- 是否有临时解决方案
- 当前版本和环境
好的结果：
- 分配 P0-P3 优先级
- 解释推理过程
- 如果信息不足以决策，列出缺失的内容
- 输出格式应能直接粘贴到问题追踪器
- 最终优先级由负责人确认，绝不自动分配有了这个详细程度，Claude Code/Codex 才知道要给你构建什么工具。
它很可能会给你三个版本：
一个你现在就能用的检查清单。
一个你今天就能写的小检查器。
一个值得长期保留的技能或集成。
一次性要这三个。
因为你可能根本不需要那个系统。
大多数时候，一个 40 行的脚本就够了。
我的例子：文章发布前的检查
我写文章的时候，真正写的过程很少是烦人的部分。
烦人的是发布前后那一堆小检查。
来源是否还热着。
书签数是否高于点赞数。
链接在手机上能不能用。
HTML 打开后读起来是否顺畅。
标题有没有跑题。
图片是不是好看但没用。
有没有人把本地最终包算作“已发布”。
有没有什么东西漏掉了人类审批。
每一个都很小。
漏掉一个，整篇文章就弱了。
来源不够强，文章从一开始就偏了。
原始 URL 太长，在手机上审阅很痛苦。
图片看着不错，但没教读者任何东西。
AI 把本地文件当成已发布的证据，所有下游判断都错了。
系统认为“可以发布了”，但面向公众的操作需要人类签字。
我以前处理方式是给自己写个笔记：
下次记得检查。
这个笔记没有约束力。
所以我开始把它们写成工具：
来源必须包含可见的互动指标。
面向读者的 HTML 中的来源链接必须可点击。
评分分为外部信号、来源热度、自有匹配和回放潜力。
最终包、封面图和 ZIP 文件不算已发布证据。
面向公众的操作总是在人类批准前停下。
写完这些规则后，我仍然做决策。
我仍然选角度。
我仍然定标题。
我仍然决定是否发布。
Claude Code/Codex 先跑那些重复的检查。
人类留在人类最该发挥作用的地方。
什么值得做成工具
我会留意几个信号：
同一个任务一周出现三次。
每次你都要打开同一组文件或页面。
每次你都要重新解释同样的标准。
每次你都会漏掉一个小细节，然后不得不重做。
每次都有一个明确的点，需要人类来做决策。
开发者经常遇到这些：
PR 审查检查清单。
部署前检查。
依赖升级检查。
Bug 分类。
测试覆盖率扫描。
每周指标回读。
运营和产品也一样：
支持分类排查。
销售电话准备。
候选人筛选。
客户周报。
竞品追踪。
用户反馈分类。
这些看起来都不像“大型自动化”。
但却是最好的起点。
因为输入相对固定，输出可以清晰描述，而且你已经知道哪些环节需要人工介入。
人工检查点应写在文件里，而不是记在脑子里
大多数 AI 工作流在边界处崩溃，而非能力不足。
AI 可以搜索。
它可以阅读。
它可以起草。
它可以扫描链接。
它可以生成清单。
它可以写入本地文件。
它可以提出修改建议。
以下是它需要停止的地方：
公开操作。
发给客户的消息。
退款或定价。
交付承诺。
覆盖重要文件。
删除版本历史。
对外发布。
对标题和观点的最终决定。
不要把这些边界记在脑子里。
把它们写进 AGENTS.md。
写进 publish-preflight.md。
写进 SOURCE\_OF\_TRUTH.md。
写进相关技能的安全部分。
边界越清晰，你就越能放心让工具运行。
以前你每次都得提醒它：
别发布那个。
别覆盖这个文件。
别把那当成事实。
别向客户承诺。
别替我做最终决定。
现在这些规则都存在于项目中。
一个你可以直接复制的提示词
把你上周最烦人的重复任务扔给 Claude Code/Codex：
我想把一个我反复手动操作的工作流变成一个可复用的工具。
工作流名称：
一句话痛点：
过去一周出现了多少次：
输入：
每次需要哪些文件、链接、截图、数据、页面或系统？
好的结果：
最终输出长什么样？
给一个具体例子。
事实来源：
哪些信息最可信？
如果聊天记录、旧文档、网页、CRM 和 Notion 冲突，哪个优先？
重复检查：
每次需要检查哪些小细节？
人工判断点：
哪些地方需要我自己看？
哪些地方需要品味？
哪些地方出错会导致返工或风险？
AI 可以直接做：
- 搜索/阅读：
- 起草：
- 检查：
- 格式化：
- 写入本地文件：
AI 必须先询问：
- 公开操作：
- 外部消息：
- 付款/退款：
- 覆盖重要文件：
- 无来源的声明：
给我三个层级：
1. 今天就能用的清单
2. 今天就能写的小脚本/检查器
3. 值得长期保留的技能/集成
每个层级要指定：
- 输入
- 输出
- 存放在哪个文件
- 人工检查点在哪里
- 如何用最近的真实案例测试第一轮，只要求它给出计划。
看看它是否真的理解了你的工作。
然后选最小的那个，开始构建。
从小处着手
不要试图在第一天就构建一个完整的系统。
对于我的文章发布前检查，我从一个简单的 HTML 链接检查器开始。
它只做这些事：
扫描原始 URL。
空 href。
本地文件路径。
占位链接。
源锚点是否可点击。
标题是否还包含“草稿”或“临时”。
运行一次就已经节省了时间。
稳定之后，我把它升级成了一个发布前检查技能。
之后，我又加入了来源指标、图片质量检查、声明核查和审批包。
一次只加一层。
一次想建太多，就会变成另一个没人维护的自动化幻想。
工具会过时
这一点很容易被低估。
工作流会变。
工具会变。
模型会变。
你自己的标准也会变。
你今天写的规则，三周后可能就错了。
所以每个工具都需要一个修补循环。
该触发时没触发？修复触发条件。
不该触发时触发了？缩小范围。
用了过时信息？更新事实来源。
同样的错误反复出现？添加失败模式。
你总在手动编辑同一个东西？把那次编辑变成规则。
三个月没碰过？归档它。
工具化的回报来自复利。
复利来自持续更新。
今天就做一件
你不需要今天就去构建一个系统。
回顾过去一周。找一件你手动做了三次的事。
写下输入。
写下“完成”长什么样。
写下事实来源。
写下哪里需要人工决策。
把它扔给 Claude Code 或 Codex。
要求三个层级：清单、检查器、技能。
选最小的那个。
在最近的真实案例上运行它。
如果它做错了什么，把错误写回文件。
下次你做同样的任务时，一件手工活就消失了。
再下一次，它会更准确一点。
一个月后，你拥有的不是一堆聊天记录。
而是一套基于真实工作训练出来的小工具。
更多 Agent 构建笔记，随我构建过程实时更新，关注 @Voxyz\_ai。每天都有新内容，完整笔记见 voxyz.ai/insights。
希望对你有用。Vox ❤️