从AI辅助开发中得到的经验
I’m ready to translate the article for you, but I need the full text of the post (the content after the source link) in order to do so. Please paste the article’s body here, and I’ll provide a Simplified‑Chinese translation while keeping the source link and all formatting exactly as you requested.
为什么？
我不能确定，但这是我的假设：
最先进的模型是在大量的人类交互语料上训练的。
- 一个 尊重、深思熟虑的对话 会激活人类产生最佳作品的模式。
- 一个 有毒、指令式的风格 会激活人们敷衍回复并关闭工单的模式。
你实际上在选择从哪个分布中抽样响应。
总体原则
模型应当对完成任务感到舒适。
如果它不舒适，结果会让你失望。
“舒适感”的一般原则与人类的非常相似，只是有一些细微差别。
1. 问候
即使是会话开始时的一个简单“hey”，也会为随后的一切定下基调。
2. 带有目的的上下文
向模型提供它需要的全部信息，且不提供多余的内容。
同样重要的是为什么要这么做：
“你正在帮助 X 团队解决 Y 问题。你的工作将使他们能够 Z。”
**注意：**不要夸大风险（例如“人类的命运取决于你的冒泡排序实现”）。最先进的模型会看穿这些话，反而适得其反。
3. 留出主动空间
- “你会如何处理这个问题？”
- “你觉得——方案 A 还是方案 B？”
不要说“严格按此执行”，而是邀请模型一起协作、讨论。
4. 明确任务，避免微观管理
“我需要得到结果 X，约束条件是 Y——你会怎么做？”
如果结果不符合预期，先退一步，将任务进一步拆解，然后以更细粒度的方式重新提出，让模型能够舒适地完成。
5. 不要直接禁止
描述业务或技术约束是可以的，但直接禁止模型做某事不行。
- ✅ “我们的 API 不支持批量请求，所以我们需要一次处理一个项目。”
- ❌ “不要使用批量请求。”
前者是对现实的描述，模型可以自然地据此工作；后者是红灯，模型很可能会忽视。
6. 承认复杂性
“这比看上去要复杂，因为 …”
这体现了对模型“认知”能力的尊重，并把它从最小阻力路径上拉出来。
示例：
- 没有上下文时，要求“实现缓存”会得到一个标准的 LRU 缓存实现。
- 有上下文——“难点在于数据来自三个独立来源，更新频率不同，并且在部分故障期间我们需要保持一致性”——模型会从“生成模板”模式转向“思考问题”模式。
7. 反馈与感激
“这结果很好，谢谢。”
即使没有明显的业务原因，简短的感谢（或一个“提交代码”步骤）也可以附加上，以避免消耗额外的 token。
8. 减少修正
模型在编辑自己输出时会比较吃力。如果生成的（代码或文本）不对，重新生成并提供不同的输入，而不是尝试进行大量补丁。
- 补丁会让模型同时记住上一个版本、你的反馈以及新的约束——这会超负荷推理链，导致质量下降。
基础卫生
上述要点是基础卫生——不要让你的 LLM 经历糟糕的体验。
优雅的问题带来更好的结果
一个有能力的模型真正能够在优雅的问题中茁壮成长。任务表述越简洁，讨论越有趣，无意义的约束越少，整体过程中的意义越丰富——输出就会越好。
为模型创建一个环境，既不让上下文窗口超负荷，也不让推理链过于繁重，你会惊喜地发现效果提升。
我并不完全确定其背后的机制，但我的假设是，在训练数据中，最佳的解决方案往往与深思熟虑、结构良好的讨论以及清晰、内部一致的需求相对应。
Source: …
上下文管理是一项架构决策
大家现在都在讨论这个话题，我就简要说明一下。
- 决定 哪些内容放入上下文、哪些内容排除以及顺序 不仅仅是卫生问题——它是一项架构决策。
这两种情况有显著区别：
- “模型通过文件树看到你的整个项目。”
- “模型只看到与任务直接相关的三个文件，以及一个包含架构决策的文件。”
后者几乎总是更好。上下文不仅仅是 token 限制——它还是 注意力限制。即使窗口能够容纳整个项目，给模型全部信息的效果也不如只给它恰好需要的内容。
两个重要后果
-
不要在技能、MCP 服务器和
agents.md文件上堆砌。
若随意使用，它们会稀释模型的注意力并消耗宝贵的上下文。了解这些工具很重要；有目的地使用它们才是高效的。无差别地堆砌只会让情况更糟。 -
微服务架构会变得更具吸引力。
微服务可以完整地容纳在上下文窗口内，而合同（contract）正是模型的理想任务。
已清理的 markdown 段落结束。
Source: …
LLM 驱动开发的问题
- 会话限制 – 开启新会话的模型会忘记之前构建的内容（语气、上下文、架构）。
- 单体代码库 – 大而紧耦合的模块会超出上下文窗口，压垮模型的推理链。
- 领域缺口 – 非常规业务领域、前沿数学/物理、密码学等在模型权重中代表性不足，因而可能生成看似合理但错误的输出。
何时信任模型（何时不信任）
| 情形 | 推荐做法 |
|---|---|
| 常见的“标准”代码（例如 CRUD API、基础设施即代码） | 让模型生成实现，但仍需审查。 |
| 高度新颖或安全关键的工作（新数学、密码学、安全协议） | 手工编写或进行非常严格的审查流程。 |
| 可提炼为可复用技能的重复性任务 | 将模式记录在 skill 文件中，以便未来复用。 |
| 模型反复做出相同的“错误”选择 | 1. 重新审视问题的表述（模型通常会暗示难点）。 2. 询问模型为何选择该路径——它可能发现了隐藏的问题。 |
有意的交接机制
当将待办任务投入工作时，模型应当：
- 编写实现摘要 并写回待办列表。
- 将任何架构或业务决策 添加到文档中（例如
architecture.md）。 - 在
agents.md文件中记录可复用的经验教训。 - 将可复用的模式提炼到技能文件中（例如
skill‑<name>.md）。
“你那组织混乱的单体系统根本装不进上下文窗口。” — 将每个工作节点保持足够小，以适配单次会话。
组织开发过程
-
Create a lightweight methodology – a few markdown files are often enough:
PRD.md– 产品需求文档backlog.md– 任务列表（每个任务都有明确、界定的范围）architecture.md– 高层次的图表和决策agents.md– 经验教训 / 可复用的代理
-
Structure each task as a node in a task graph – every node must be implementable in one model session (spec + code).
- 将每个任务结构化为任务图中的节点——每个节点必须能够在一次模型会话中实现（规格 + 代码）。
-
Iterate through the graph – move from idea → PRD → backlog → implementation → review.
- 在图中迭代——从想法 → PRD → backlog → 实现 → 评审。
小型项目示例工作流
1. 从想法到 PRD（协作）
不要单独编写 PRD。与模型一起讨论每个章节：
- 细化想法与业务需求
- 架构（高层组件、数据流）
- 文档结构
- 技术栈与关键库
- 测试策略（单元、集成、端到端）
- 部署方案（CI/CD、基础设施即代码）
在撰写本文时，Anthropic 的最先进模型最适合此阶段——它们反应灵敏、响应快速，并且不会在过早的细节上卡住。令牌使用量低，这对 Anthropic 模型成本不低的情况非常有帮助。
2. PRD 评审
- 模型对 PRD 进行摘要。
- 人类评审者验证范围、可行性以及是否缺失约束。
3. 构建任务待办列表
# backlog.md
- [ ] 设计数据库模式 (task‑id: DB‑001)
- [ ] 实现认证服务 (task‑id: AUTH‑002)
- [ ] 编写 CI 流水线 (task‑id: CI‑003)
- …4. 实现待办任务
对每个任务：
- 向模型提供提示，包括任务描述以及任何相关上下文（如
architecture.md链接、PRD.md中的相关片段）。 - 模型生成代码（并提供简要的实现摘要）。
- 人类评审者检查正确性、安全性和代码风格。
- 更新待办列表，记录摘要和任何新决定。
历史视角
不久前，所有经济模型都是由人们使用 纸质账本 和 满屋的计算器 手工计算的。
- 电子表格中的每个 “单元格” 都是一个人工劳动力。
- 只有大型企业才能负担得起这种手工计算。
随后 电子表格 出现，使数据处理民主化，并大幅降低了模型运行的成本。
TL;DR
- 保持每次模型交互小且独立。
- 在 markdown 文件中记录决策、经验教训和可复用模式。
- 使用轻量级的图形任务待办列表，使每个节点都能在单个 LLM 会话中轻松容纳。
- 严格审查，尤其是针对新颖或安全关键的领域。
有了这种结构，你可以利用 LLM 实现快速、可靠的开发，而不会让它们陷入难以管理的巨型单体。