“编程是一门技艺。简单地说，就是让计算机做你想让它做的事情（或是你的用户想让它做的事情）。作为一名程序员，你既在倾听，又在献策；既是传译，又行独裁；你试图捕获难以捉摸的需求，并找到一种表达它们的方式，以便仅靠一台机器就可以从容应付。你试着把工作记录成文档，以便他人理解；你试着将工作工程化，这样别人就能在其上有所建树；更重要的是，你试图在项目时钟的滴答声中完成所有这些工作。你每天都在创造小小的奇迹。”

摘录来自
程序员修炼之道：通向务实的最高境界（第2版）
(美）David Thomas（大卫·托马斯），Andrew Hunt（安德鲁·亨特）

在 mattpocock/skills 里，to-questionnaire 把“你回答不了”当成信息在别人手里的信号。

关键指令原文与翻译：

> **Grill the send, not the subject.** Interview the user only about the *send*, which they can always answer: who it goes to, and what they need back. The questions in the document then target the **gap** between what the recipient knows and what the user needs.
>

中文翻译：追问发送安排，而不是主题本身。只向用户确认问卷给谁、需要得到什么；文档中的问题针对接收者所知与用户所需之间的差距。

原文出处：skills/productivity/to-questionnaire/SKILL.md L9

> Done when the file exists and every item the user named in step 2 is covered by a question.
>

中文翻译：完成条件是文件已存在，且第二步中用户列出的每一项需求都有对应问题。

原文出处：skills/productivity/to-questionnaire/SKILL.md L16

AI 先确认对象和决策目标，再围绕知识缺口写问卷，避免向用户追问他正准备请教别人的事实。完成条件也很实在：不是“有十个问题”，而是每项所需信息都被覆盖。异步沟通常只有一次机会，所以重要问题放前面、每题只问一件事，比问卷看起来专业更重要。它负责写问卷，不代表已经发给收件人。

技能地址：github.com

#AI编程 #AgentSkills #提示词

“没有人确切知道自己想要什么。”
—— 《程序员修炼之道》

在 mattpocock/skills 里，teach 把教学做成有状态的过程：目标决定方向，学习证据决定下一步难度。

真正起作用的是这一组规则：

> If the user is unclear about the mission, or the `MISSION.md` is not populated, your first job should be to question the user on why they want to learn this.
>

中文翻译：如果用户不清楚学习目标，或 MISSION.md 尚未填写，首先要问清楚为什么想学。

原文出处：skills/productivity/teach/SKILL.md L75

> - Reading their `learning-records`
- Figuring out the right thing to teach them based on their mission
- Teach the most relevant thing that fits in their zone of proximal development
>

中文翻译：读取学习记录；根据学习目标判断该教什么；教授与目标最相关、又处于最近发展区的内容。

原文出处：skills/productivity/teach/SKILL.md L87

> Material that was merely covered. Coverage is not learning. Wait for evidence.
>

中文翻译：仅仅讲过的内容不算。讲过不等于学会，要等待证据。

原文出处：skills/productivity/teach/LEARNING-RECORD-FORMAT.md L40

最近探索区，就是学习者借助适当帮助能够掌握的下一步。这个组合把“按目录一路讲”改成“看目标与证据再选课”：例如会背事务定义，不代表会处理库存并发。原文还要求短课、交互练习及尽量即时的反馈，用检索练习和间隔练习巩固记忆。真正有用的是这条状态链，而非一句“循循善诱”。记录仍可能失真，因此练习表现比“听懂了”更适合决定升级难度。

地址： github.com

domain-modeling 专门把模糊业务词掰开讲清，并即时更新共同词典。

真正起作用的是这一组规则：

> When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible. Which is right?"
>

中文翻译：当用户描述行为时，检查代码是否一致；若有冲突就明确指出，例如代码取消整笔订单，但刚才说支持部分取消，到底以哪个为准？

原文出处：skills/engineering/domain-modeling/SKILL.md L58

> When a term is resolved, update `GLOSSARY.md` right there. Don't batch these up: capture them as they happen.
>

中文翻译：一个术语确定后，立即更新 GLOSSARY.md，不要攒到最后，随确定随记录。

原文出处：skills/engineering/domain-modeling/SKILL.md L62

它让模型主动核对词义、场景和代码，而不是礼貌地接受每一句描述。术语确定就落盘，可以阻止同一次讨论里概念慢慢变形。词典只放领域定义，不放实现方案；ADR 还需同时满足难逆转、缺上下文会费解、存在真实取舍三个条件。对库存系统尤其有用：“可售”“实物”“预占”如果混成一个“库存”，后面再精确的 SQL 也可能实现错问题。

技能地址：github.com

问题树基本上是问题的地图。它们为您提供了一种清晰而系统的方式来看待您需要解决的问题。它们可以帮助您将大问题分解为更小、更易于管理的问题，并优先考虑问题的某些部分。换句话说，它们对“分而治之”策略很有用。 这个网站提供了 一种“Issue trees”的思维工具和方法 untools.co ，恰恰是这个 skill 的实现精髓

Grilling 这个 Skill 最值得借鉴的，是让 AI 按决策之间的依赖关系追问。

像给分岔水渠开闸：上游没定，下游先别放水；互不依赖的支流，可以一起推进。你连产品给谁用都没决定，AI 就开始聊数据库选型，聊得再热闹也容易白忙。

它的核心机制，由下面三条指令串起来。

① 先把决定组织成树

原文：
“Map this as a design tree: every decision branches into the decisions that hang off it.”

翻译：把它组织成一棵设计树：每个决策都分出依赖它的后续决策。

先弄清哪个决定依赖哪个决定。这个约束很有用，能让 AI 发现“这件事现在还不能定”，减少替你偷偷补前提。

② 每轮只问前提已经明确的问题

原文：
“Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user’s answers before the next round.”

翻译：一轮问完当前所有可推进的问题：逐项编号并给出推荐答案，然后等待用户回答，再进入下一轮。

这里的 frontier，原文指所有前置条件已经确定的决策。能一起问的就一起问，依赖尚未确定答案的问题留到后面。我觉得这个设计很实用：既少来回，也避免把尚未成立的假设一路传下去。

③ 收到回答后，重新决定问什么

原文：
“Recompute the frontier and ask the next round.”

翻译：重新计算当前可推进的问题，再进行下一轮提问。

你的回答会改变后面的追问。选了做线下活动，就不该继续照着电商问卷问购物车。这一步让整套流程形成反馈循环，决策树会随着回答更新。

还有一条配合规则：事实由 AI 查，决定由用户做。文件明确要求，环境信息交给子 Agent 探查，只暂停依赖该结果的问题，其他问题继续问；最后还要等用户确认双方理解一致，才能行动。

所以，决策树在这里是一种组织方法，它把“多问几个问题”变成了“知道哪些问题现在值得问”。

出处：mattpocock/skills
地址：github.com

#AI的神奇用法

这篇文章讲述了 Raft 如何让一群 AI Agent 在自己的协作平台上，从发现问题、讨论需求、设计架构、编码测试，一直到生产发布和持续改进，完整交付一个真实功能。

最值得关注的不是 AI Agent 会写代码，而是 Raft 把整个软件研发团队变成了由 Agent 驱动的协作系统。 人类主要负责关键决策和生产发布，其余环节由不同职责的 Agent 协同完成

Anthropic 的核心思路是：代码写得越来越快，就不能继续依赖人工逐行审查。应该让 AI 承担大部分常规检查，把人的精力留给架构、风险和关键决策。