即刻App年轻人的同好社区
下载
置顶Yibie 的自我策展
我整理之前发过的帖子，这些是值得推荐一看的。也顺道向你暴露我的世界观、性格、兴趣和观点，有机会的话交个朋友😊
✨ AI 与新世界
得到 Prompt 系列（共 18 个） ⭐️已被“提示词图书馆收录”
m.okjike.com
Promopt: 文章精炼大师
web.okjike.com
Promopt: 概念卡片制作专家
web.okjike.com
Promopt: PPT 大纲制作助手 ⭐获得即刻精选推荐
web.okjike.com
Promopt: Kiweb. 文章精华浓缩专家
web.okjike.com
开发 12 Weeks LifeRPG 背后的过程与思考
web.okjike.com
用 AI 帮忙总结笔记（测试了 ChatGPT、Gemini、Kiweb.、豆包）
web.okjike.com
微软 CTO Kevin Scott 接受 every 访谈
web.okjike.com
吴恩达总结 AI 工程师制作 Promopt 的经验
web.okjike.com
OpenAI 2024 年春季发布会源文件， 包括演讲稿和演示用代码
web.okjike.com
视频内容识别是 Gemini Pro 1.5 的杀手锏
web.okjike.com
Perplexity 的官方 Promopt
web.okjike.com
大模型公司对 Token 的计算方法都不一样
web.okjike.com
AI 与创作者经济
web.okjike.com
------------------------------------
🤔我对这个世界有点看法
every 长文: AI 将冲击广告业, 后果很严重
web.okjike.com
Vision Pro 之我见
web.okjike.com
社会生活的趋同让人恐惧
web.okjike.com
「探索式」笔记法 ⭐获得即刻精选推荐
web.okjike.com
子弹日记法
web.okjike.com
商业价值的 3 个重要特征
web.okjike.com
Arc 这家公司的特点
web.okjike.com
新产品形态: Jina AI 将 URL 变为 API
web.okjike.com
------------------------------------
📒囤了一些清单
值得推荐的豆瓣小组
web.okjike.com
包豪斯设计的精华链接
web.okjike.com
Design Engineer 的 Twitter List
web.okjike.com
------------------------------------
📖️那些值得推荐的好书
读完斯多葛主义代表人物塞涅卡的书信集 <短暂的生命>
web.okjike.com
程序员超强大脑笔记
web.okjike.com
读完<巨人的工具>
web.okjike.com
读完<为什么伟大不能被计划>
web.okjike.com
精要主义读书笔记
web.okjike.com
读《了不起的盖茨比》
web.okjike.com
------------------------------------
💭️脑海里闪过的一句话
天才税
web.okjike.com
高度抽象的现代生活损害人类天生的类比能力
web.okjike.com
你能列出充分反映时代精神的 3 家公司吗？
web.okjike.com
解决拖延症的办法是找出之前最想完成但一直没做的事
web.okjike.com
美 = 深刻的简洁
web.okjike.com
尊重常识 = 不犯基本错误
web.okjike.com
与其花 1 小时如昙花一现, 不如花 10 倍时间震惊四座
web.okjike.com
这个世界有种人，以好人为食。
web.okjike.com
最难沟通的，是被灌输了标准答案的人
web.okjike.com
拖延 = 甩锅给未来的自己
web.okjike.com
折腾的定义
web.okjike.com
------------------------------------
🛠喜欢折腾工具
开启 Mac 系统自带白噪音音乐的方法
web.okjike.com
20-20-20 护眼原则
web.okjike.com
用哔哩哔哩替代网易云音乐
web.okjike.com
中国著名羽毛球运动员郑思维学习英语的工具和方法
web.okjike.com
------------------------------------
📁未归类的答案
「参考答案」的策展原则
web.okjike.com
我整理之前发过的帖子，这些是值得推荐一看的。也顺道向你暴露我的世界观、性格、兴趣和观点，有机会的话交个朋友😊
✨ AI 与新世界
得到 Prompt 系列（共 18 个） ⭐️已被“提示词图书馆收录”
m.okjike.com
Promopt: 文章精炼大师
web.okjike.com
Promopt: 概念卡片制作专家
web.okjike.com
Promopt: PPT 大纲制作助手 ⭐获得即刻精选推荐
web.okjike.com
Promopt: Kiweb. 文章精华浓缩专家
web.okjike.com
开发 12 Weeks LifeRPG 背后的过程与思考
web.okjike.com
用 AI 帮忙总结笔记（测试了 ChatGPT、Gemini、Kiweb.、豆包）
web.okjike.com
微软 CTO Kevin Scott 接受 every 访谈
web.okjike.com
吴恩达总结 AI 工程师制作 Promopt 的经验
web.okjike.com
OpenAI 2024 年春季发布会源文件， 包括演讲稿和演示用代码
web.okjike.com
视频内容识别是 Gemini Pro 1.5 的杀手锏
web.okjike.com
Perplexity 的官方 Promopt
web.okjike.com
大模型公司对 Token 的计算方法都不一样
web.okjike.com
AI 与创作者经济
web.okjike.com
------------------------------------
🤔我对这个世界有点看法
every 长文: AI 将冲击广告业, 后果很严重
web.okjike.com
Vision Pro 之我见
web.okjike.com
社会生活的趋同让人恐惧
web.okjike.com
「探索式」笔记法 ⭐获得即刻精选推荐
web.okjike.com
子弹日记法
web.okjike.com
商业价值的 3 个重要特征
web.okjike.com
Arc 这家公司的特点
web.okjike.com
新产品形态: Jina AI 将 URL 变为 API
web.okjike.com
------------------------------------
📒囤了一些清单
值得推荐的豆瓣小组
web.okjike.com
包豪斯设计的精华链接
web.okjike.com
Design Engineer 的 Twitter List
web.okjike.com
------------------------------------
📖️那些值得推荐的好书
读完斯多葛主义代表人物塞涅卡的书信集 <短暂的生命>
web.okjike.com
程序员超强大脑笔记
web.okjike.com
读完<巨人的工具>
web.okjike.com
读完<为什么伟大不能被计划>
web.okjike.com
精要主义读书笔记
web.okjike.com
读《了不起的盖茨比》
web.okjike.com
------------------------------------
💭️脑海里闪过的一句话
天才税
web.okjike.com
高度抽象的现代生活损害人类天生的类比能力
web.okjike.com
你能列出充分反映时代精神的 3 家公司吗？
web.okjike.com
解决拖延症的办法是找出之前最想完成但一直没做的事
web.okjike.com
美 = 深刻的简洁
web.okjike.com
尊重常识 = 不犯基本错误
web.okjike.com
与其花 1 小时如昙花一现, 不如花 10 倍时间震惊四座
web.okjike.com
这个世界有种人，以好人为食。
web.okjike.com
最难沟通的，是被灌输了标准答案的人
web.okjike.com
拖延 = 甩锅给未来的自己
web.okjike.com
折腾的定义
web.okjike.com
------------------------------------
🛠喜欢折腾工具
开启 Mac 系统自带白噪音音乐的方法
web.okjike.com
20-20-20 护眼原则
web.okjike.com
用哔哩哔哩替代网易云音乐
web.okjike.com
中国著名羽毛球运动员郑思维学习英语的工具和方法
web.okjike.com
------------------------------------
📁未归类的答案
「参考答案」的策展原则
web.okjike.com
58 1621
Herdr 非常好用，但要说出它为什么好用，之前一直没找到一个堪称杀手级的情形。
最近遇到了一个，先交代背景，我用 herdr 开了很多项目，其中一个叫 spec-agents，它类似于 OpenSpec，是规范 Agent 开发行为的，我最近根据自己的认知，给它升级到了新的版本。
然后，我在另外一个项目 A 中使用新版 spec-agents，也算是实战演练，很快就发现了问题，我在项目 A 中跟 Agent 一边调整，一边聊最后让它总结。
那么在项目 A 中，获得的实战经验，如何传递给负责spec-agents 的 Agent 呢？
在 Herdr 里很简单，只需要说，「最近这段开发中，对 spec-agents 升级和改造的经验，麻烦传递给负责 spec-agents 的 Agent。」
然后，你就看着 Agent 自己调用 herdr 的命令，查看 spac-agents 的标签页，然后找到对应的 Agent，将自己总结好的经验发过去了。
这不是简单的省了复制一次两次的事情，而是像这样子，我才觉得像 AI Native 的沟通方式。
最近遇到了一个，先交代背景，我用 herdr 开了很多项目，其中一个叫 spec-agents，它类似于 OpenSpec，是规范 Agent 开发行为的，我最近根据自己的认知，给它升级到了新的版本。
然后，我在另外一个项目 A 中使用新版 spec-agents，也算是实战演练，很快就发现了问题，我在项目 A 中跟 Agent 一边调整，一边聊最后让它总结。
那么在项目 A 中，获得的实战经验，如何传递给负责spec-agents 的 Agent 呢？
在 Herdr 里很简单，只需要说，「最近这段开发中，对 spec-agents 升级和改造的经验，麻烦传递给负责 spec-agents 的 Agent。」
然后，你就看着 Agent 自己调用 herdr 的命令，查看 spac-agents 的标签页，然后找到对应的 Agent，将自己总结好的经验发过去了。
这不是简单的省了复制一次两次的事情，而是像这样子，我才觉得像 AI Native 的沟通方式。
3 00
我真的不确定别人怎么做到 AI 无人值守开发的，我觉得即便是多代理并行 ，worktree 拆分工作范围，也很难做到这一点。你始终要面对 AI 对问题的了解不如你深刻，抑或，因为自己对问题了解得不够深刻而提供的错误上下文。
如果有人可以做到精确完美地提供上下文，那么可能做到多代理，无人值守开发。然而，这仅仅是可能性，由于 AI 还会自我泛化，因此最终实现时，还会出现：
- 一些没说的，它做了;
- 一些说了的，它没做;
- 一些说了的，做歪了。
在 AI 无人值守开发时，如何面对以上三点所造成的不确定性？
如果有人可以做到精确完美地提供上下文，那么可能做到多代理，无人值守开发。然而，这仅仅是可能性，由于 AI 还会自我泛化，因此最终实现时，还会出现：
- 一些没说的，它做了;
- 一些说了的，它没做;
- 一些说了的，做歪了。
在 AI 无人值守开发时，如何面对以上三点所造成的不确定性？
8 30
方案规划，还是让 Claude + ast-grep 来比较好，一是读取文件，懂读取关键部分，二 ast-grep 刚好填补了视野有时过窄的问题。
如果让 GPT 来规划，由于防御性倾向过重，反而读了太多不关键的文件，上下文污染严重，跑着跑着就跑偏了，看着 Codex 里长长的工具调用，一种傻蛮傻蛮的感觉。
但是，具体实现，GPT-Luna-max 真的非常好，思考质量高，代码质量也高。唯一的缺点是 GPT 本身很慢，得加 /fast。
所以我现在 Hardr 里一般就是开着一个 Claude 和一个 Codex，一个负责规划，一个负责执行。
我觉得在大家引入 Multi-Agent 之前，还是先学习一下如何结对编程比较好。不然正如之前推友所说，Multi-Agent 就是一个分布式系统，状态超多容易炸，本来难搞。
先从简单入手吧，我今天实践了一天，感觉效果非常不错。
如果让 GPT 来规划，由于防御性倾向过重，反而读了太多不关键的文件，上下文污染严重，跑着跑着就跑偏了，看着 Codex 里长长的工具调用，一种傻蛮傻蛮的感觉。
但是，具体实现，GPT-Luna-max 真的非常好，思考质量高，代码质量也高。唯一的缺点是 GPT 本身很慢，得加 /fast。
所以我现在 Hardr 里一般就是开着一个 Claude 和一个 Codex，一个负责规划，一个负责执行。
我觉得在大家引入 Multi-Agent 之前，还是先学习一下如何结对编程比较好。不然正如之前推友所说，Multi-Agent 就是一个分布式系统，状态超多容易炸，本来难搞。
先从简单入手吧，我今天实践了一天，感觉效果非常不错。
4 10
其实有一个可笑的事情，大家使用 AI 或 Vibe Coding 的时候，更多像是在执行一个「童年补完计划」，实现旧日梦想。
但 AI 是新的时代，这个时代下，应当拥有什么样的梦想呢？
但 AI 是新的时代，这个时代下，应当拥有什么样的梦想呢？
8 20
在多次迭代更新后，上下文会腐坏，此时新起 Session，让 subagent 重新读整个项目的代码，比一个 agent 自己读要完整许多。
这是我实践中，觉得 subagent 最大的作用。
当前 Multi-Agent 最大的价值是「心跳机制」，定时来检查一番任务循环。换言之，这套方法论还没超越 25 年提出的「拉尔夫循环」。
至少，每一次启动，拉尔夫循环都会清理上下文，让 Agent 智能最高。
而 Multi-Agent 上下文依然是熵增的，没有任何有效的证据证明 Multi Agent 可以令上下文空间熵减
这是我实践中，觉得 subagent 最大的作用。
当前 Multi-Agent 最大的价值是「心跳机制」，定时来检查一番任务循环。换言之，这套方法论还没超越 25 年提出的「拉尔夫循环」。
至少，每一次启动，拉尔夫循环都会清理上下文，让 Agent 智能最高。
而 Multi-Agent 上下文依然是熵增的，没有任何有效的证据证明 Multi Agent 可以令上下文空间熵减
4 12
最近积极使用 Herdr 等 Agent 终端来启动多代理协同执行。和之前几次一样，并未感受到真正效率上的提升，问题解决依然优势在我，来多几个 Agent 都没用。
反而 Token 的消耗量「唰」一下上去了。我观察了一下，这个消耗是来自于担任指挥的 Agent 会不停发命令去查看别的 Agent 的工作完成没有，而且过程感觉比人类要焦躁得多了。
很多 Token 浪费在阅读「工具调用」的日志记录上，令人哭笑不得。
反而 Token 的消耗量「唰」一下上去了。我观察了一下，这个消耗是来自于担任指挥的 Agent 会不停发命令去查看别的 Agent 的工作完成没有，而且过程感觉比人类要焦躁得多了。
很多 Token 浪费在阅读「工具调用」的日志记录上，令人哭笑不得。
6 10
Google 工程主管 Addy Osmani 把 2026 年的编码工作流摊开：
经典软件工程纪律在 AI Coding 时更重要了。
《我 2026 年的 LLM 编码工作流》
My LLM coding workflow going into 2026
AI 编程助手在 2025 年成了游戏规则改变者，但有效驾驭它们需要技巧和结构。这些工具极大地提升了 LLM 对真实编码能做的事，很多开发者（包括我）都拥抱了它们。在 Anthropic，工程师如此重度采用 Claude Code，以至于今天 Claude Code 约 90% 的代码是它自己写的。然而，用 LLM 编程不是一个按钮魔法体验——它"困难且反直觉"，要拿到好结果需要学习新的模式。批判性思维仍然是关键。经过一年多项目，我收敛到一个和许多有经验开发者正在发现的工作流相似的东西：把 LLM 当作一个强大的结对程序员，它需要清晰的方向、上下文和监督，而不是自主判断。
在这篇文章里，我会分享 2026 年我如何规划、编码和与 AI 协作，提炼我自己经验和社区集体学习的技巧与最佳实践。这是一种更自律的"AI 辅助工程"方法——激进地利用 AI，同时对产出的软件保持问责。
从清晰的计划开始（先规格后代码）
别把愿望直接扔给 LLM——先定义问题、规划解决方案。
一个常见错误是带着模糊提示直接进入代码生成。我的工作流里（也是很多其他人的），第一步是和 AI 一起头脑风暴详细规格，然后列出逐步计划，然后才写任何实际代码。对新项目，我会描述想法，让 LLM 迭代地向我提问，直到我们把需求和边界情况都厘清。最后，我们把所有内容编译成一份完整的 spec.md——包含需求、架构决策、数据模型，甚至测试策略。这份规格构成开发的基础。
接下来，我把规格喂给一个带推理能力的模型，提示它生成项目计划：把实现拆成合乎逻辑的小任务或里程碑。AI 基本是在帮我做一次迷你"设计文档"或项目计划。我经常迭代这份计划——编辑、让 AI 批评或细化——直到它连贯完整。然后我才开始编码。这笔前置投入感觉慢，但回报巨大。就像 Les Orchard 说的，这等于做一次"15 分钟的瀑布"——一个快速的结构化规划阶段，让后面的编码顺畅得多。
有清晰的规格和计划意味着，当我们放出代码生成时，人和 LLM 都确切知道我们在构建什么、为什么。一句话：先规划逼着你和 AI 对齐，防止浪费循环。很多人想跳过这步，但有经验的 LLM 开发者现在把扎实的规格/计划当作工作流的基石。
把工作拆成小的迭代块
范围管理就是一切——喂给 LLM 可管理的任务，而不是一次整个代码库。
我学到的一个关键教训是避免向 AI 要大型整体输出。相反，我们把项目拆成迭代步骤或工单，一个一个地攻克。这镜像了良好的软件工程实践，但有人在循环里时它更重要。LLM 在收到聚焦提示时表现最好：一次实现一个函数、修一个 bug、加一个功能。比如规划之后，我会提示代码生成模型："好，让我们实现计划的第 1 步"。我们编码、测试，然后进入第 2 步，如此类推。每块小到 AI 能在上下文里处理、你能理解它产出的代码。
这个方法防模型脱轨。如果你一次要太多，它很可能困惑或产出难解的"一团乱"。有开发者报告，当他们试图让 LLM 生成应用的大块时，结果是不一致和重复——"像 10 个开发者在没互相沟通的情况下工作"。我感受过那种痛；解法是停下、后退、把问题拆成更小的块。每轮迭代，我们带上已构建内容的上下文，增量添加。这也很好地配合测试驱动开发（TDD）——我们可以边走边为每块写或生成测试。
几个编码 agent 工具现在显式支持这种分块工作流。比如，我经常生成一个结构化的"提示计划"文件，包含每个任务的提示序列，这样 Cursor 之类的工具能逐个执行。关键点是避免巨大的跳跃。通过小循环迭代，我们大幅降低灾难性错误的概率，并能快速纠偏。LLM 擅长快速、受限的任务——利用这一点。
提供充分的上下文和指导
LLM 的好赖取决于你提供的上下文——展示它们相关代码、文档和约束。
在代码库上工作时，我确保把 AI 表现好所需的全部信息喂给它：它要修改或引用的代码、项目的技术约束、以及任何已知陷阱或首选方法。现代工具有帮助：Anthropic 的 Claude 可以在"Projects"模式下把整个 GitHub 仓库导入上下文；Cursor 或 Copilot 这类 IDE 助手自动把打开的文件包含进提示。但我经常更进一步——如果怀疑模型没有某些内容，我会用 MCP（如 Context7）或手动把代码库或 API 文档的重要部分复制进对话。
专家 LLM 用户强调这个"上下文打包"步骤。比如做一次"大脑倾倒"——把模型在编码前应该知道的一切倒出来，包括：高层目标和不变式、好解决方案的例子、以及要避免的方法的警告。如果我让 AI 实现一个棘手的方案，我可能会告诉它哪些 naive 方案太慢，或者从别处提供一个参考实现。如果我用一个冷门库或全新 API，我会把官方文档或 README 贴进去，这样 AI 不是盲目飞行。所有这些前置上下文都大幅提升输出质量，因为模型不是在猜——事实和约束就在它面前。
现在有工具可以自动化上下文打包。我试过 gitingest 或 repo2txt 这类工具，它们把你的代码库相关部分"倾倒"成一个文本文件给 LLM 读。处理大项目时它们是救星——生成一个关键源文件的 output.txt 包，让模型消化它。原则是：别让 AI 在残缺信息上运行。如果修一个 bug 需要理解四个不同模块，就展示那四个模块。是的，我们必须注意 token 上限，但当前前沿模型有相当大的上下文窗口。明智地使用它们。我经常只选任务相关的那部分代码，并明确告诉 AI 哪些不要关注（省 token）。
我觉得 Claude Skills 有潜力，因为它们把以前脆弱、重复的提示变成持久可复用的东西——把指令、脚本和领域专长打包成模块化能力，工具能在请求匹配时自动应用。这意味着比通用提示更可靠、更上下文感知的结果，从一次性交互转向编码可重复程序和团队知识的工作流。社区策展的 Skills 集合不少，但我最喜欢的例子是 frontend-design skill——它能"终结"LLM 生成 UI 里泛滥的紫色设计美学。在更多工具官方支持 Skills 之前，也有变通方案。
最后，用提示里的注释和规则引导 AI。我可能在一个代码片段前写："这是 X 的当前实现。我们需要扩展它做 Y，但小心别破坏 Z。"这些小提示大有帮助。LLM 是字面主义者——它们会遵循指令，所以给它们详细、有上下文的指令。通过主动提供上下文和指导，我们最小化幻觉和离谱建议，得到契合项目需求的代码。
选对模型（需要时用多个）
不是所有编码 LLM 都平等——有意图地挑选工具，别怕中途换模型。
2025 年我们被各种能力强大的编码 LLM 宠坏了。我工作流的一部分是为每个任务选择最适合的模型或服务。有时甚至并行试两个或更多 LLM，交叉检查它们如何不同地处理同一个问题。
每个模型都有自己的"性格"。关键是：如果一个模型卡住或产出平庸，换一个试试。我真的把同一个提示从一个聊天复制到另一个服务，看它能不能处理得更好。这种"模型抢椅子"能在你撞上模型盲区时救你。
另外，确保你用的是最好的版本。如果可以，用最新的"pro"级模型——因为质量很重要。是的，通常意味着付费，但生产力收益能证明它。最终，选那个"气质"和你合拍的 AI 结对程序员。我认识有人偏爱某个模型只是因为喜欢它回复的感觉。那完全合理——当你基本在和 AI 持续对话时，UX 和语气有影响。
我个人现在很多编码工作倾向于 Gemini（坦白：我在 Google 做 Gemini，自然更熟悉），因为交互感觉更自然，常常第一次就能理解我的请求。但需要时我会毫不犹豫换模型；有时第二意见能帮解决方案浮现。总结：用最适合工作的工具，记住你手头有一整支 AI 兵工厂。
在整个生命周期利用 AI 编码
命令行出现了新的 AI agent。Claude Code、OpenAI 的 Codex CLI 和 Google 的 Gemini CLI 都是 CLI 工具，你在项目目录里直接和它们对话——它们能读文件、跑测试、甚至多步修问题。我也用过 Google 的 Jules 和 GitHub 的 Copilot Agent——这些是异步编码 agent，实际上把你的仓库克隆进云 VM，在后台工作（写测试、修 bug，然后为你开 PR）。有点诡异：你发出"重构支付模块做 X"的命令，一会儿之后你收到一个带代码改动和通过测试的 pull request。我们真的活在未来。
话虽如此，这些工具不是万无一失的，你必须理解它们的局限。它们加速编码的机械部分——生成样板、应用重复改动、自动跑测试——但依然非常需要你的指导。比如，当用 Claude 或 Copilot 这类 agent 实现东西时，我经常把前面步骤的计划或待办列表提供给它，让它知道确切的任务序列。如果 agent 支持，我会在执行前把 spec.md 或 plan.md 加载进上下文。这让它保持在轨道上。
我们还没到让 AI agent 无人看管地编码整个功能并期待完美结果的阶段。相反，我以监督的方式使用这些工具：我让它们生成甚至运行代码，但盯着每一步，看到不对劲随时介入。还有 Conductor 之类的编排工具，让你在不同任务上并行跑多个 agent（本质上是规模化 AI 帮助的方式）——一些工程师在实验一次跑 3-4 个 agent 处理不同功能。我试过这种"大规模并行"方法；它能高效完成很多事，但监视多个 AI 线程也很费神！多数情况下，我一次只用一个主 agent，也许再加一个次要的做审查。
记住，这些是强力工具——你仍然控制扳机、引导结果。
保持人在循环——验证、测试、审查一切
AI 会很乐意产出看起来可信的代码，但你对质量负责——总是彻底审查和测试。我的一条基本原则是绝不盲目信任 LLM 的输出。就像 Simon Willison 精辟说的，把 LLM 结对程序员想成"过度自信、容易犯错"。它带着完全的自信写代码——包括 bug 或胡说——而且不会告诉你哪里不对，除非你抓到。所以我对待每一段 AI 生成的片段，都像来自初级开发者的代码：读一遍、跑一遍、按需测试。你必须测试它写的东西——跑单元测试，或手动演练功能，确保它真的做了它声称的事。
事实上，我把测试织进工作流本身。我早期的规划阶段经常包括为每步生成测试列表或测试计划。如果用 Claude Code 这类工具，我会指示它在实现任务后跑测试套件，有失败就调试。这种紧密反馈循环（写代码→跑测试→修复）正是 AI 擅长的——只要有测试存在。那些从编码 agent 获益最多的人，往往是有强大测试实践的人。Claude 这样的 agent 能在好测试套件作为安全网时"飞"过项目。没有测试，agent 可能心安理得地假设一切正常（"当然，都好！"）而实际上它已经弄坏了几处。所以，投资测试——它放大 AI 的用处和你对结果的信心。
即使超越自动化测试，做代码审查——人工和 AI 辅助都做。我例行暂停，逐行审查已生成的代码。有时我会开第二个 AI 会话（或不同模型），让它批评或审查第一个产出的代码。比如，我可能让 Claude 写代码，然后问 Gemini："你能审查这个函数有没有错误或改进吗？"这能抓到微妙问题。关键是别因为代码是 AI 写的就跳过审查。如果有的话，AI 写的代码需要额外审查，因为它有时表面上令人信服，却藏着人类不会立刻注意的缺陷。
我也用 Chrome DevTools MCP——和上一个团队一起做的——用于调试和质量循环，弥合静态代码分析和实时浏览器执行之间的鸿沟。它"给 agent 一双眼睛"，让它直接访问浏览器能看到的、检查 DOM、拿丰富的性能追踪、控制台日志或网络追踪。这个集成消除了手动上下文切换的摩擦，允许通过 LLM 直接做自动化 UI 测试。bug 可以基于真实运行时数据被高精度诊断和修复。
跳过人工监督的严重后果有据可查。一个重度依赖 AI 生成赶工项目的开发者，把结果描述为不一致的乱摊子——重复逻辑、错配的方法名、没有连贯架构。他意识到自己一直在"建、建、建"，没有退后一步真正看看 AI 编织出了什么。解法是一次痛苦的返工，以及再也不让事情失控到那种地步的誓言。我记住了。无论我用多少 AI，我仍然是负责的工程师。
实际操作上，这意味着只有在我理解代码之后才合并或发布。如果 AI 生成的东西绕来绕去，我会让它加注释解释，或者用更简单的术语重写。如果有什么感觉不对，我深挖——就像人类同事贡献了有危险信号的代码那样。
一切都是心态：LLM 是助手，不是自动可靠的编码者。我是资深开发者；LLM 是来加速我的，不是取代我的判断。保持这种姿态不仅产出更好的代码，也保护你自己作为开发者的成长。一句话：保持警觉，多测试，常审查。归根结底这还是你的代码库。
频繁提交，用版本控制当安全网。绝不提交你解释不了的代码。
频繁提交是你的存档点——它们让你撤销 AI 的失手、理解改动。
当和一个能快速生成大量代码的 AI 工作时，事情很容易跑偏。我通过采纳超细粒度的版本控制习惯来缓解。我早提交、频繁提交，甚至比手工编码时更频繁。每完成一个小任务或每次成功的自动编辑，我就带着清晰消息做一次 git 提交。这样，如果 AI 的下一个建议引入 bug 或混乱改动，我有一个最近的检查点可以回退（或 cherry-pick），不会丢失几小时工作。一位实践者把它比作"游戏里的存档点"——如果 LLM 会话翻车，你总能回滚到最后一个稳定提交。这条建议非常有用。当你知道必要时可以用 git reset 撤销时，大胆的 AI 重构实验压力小得多。
正确的版本控制在和 AI 协作时也有帮助。既然不能指望 AI 记住它做的一切（上下文窗口限制等），git 历史就成了宝贵的日志。我经常扫最近的提交来给 AI（或自己）简报改了什么。事实上，LLM 自己能利用你的提交历史——我把 git diff 或提交日志贴进提示，让 AI 知道哪些代码是新的、之前状态是什么。有趣的是，LLM 非常擅长解析 diff 和使用 git bisect 这类工具找 bug 是哪里引入的。它们遍历提交历史有无限的耐心，能增强你的调试。但这只有在你一开始就有整洁的提交历史时才有效。
另一个好处：带好消息的小提交基本上记录了开发过程，做代码审查（AI 或人类）时有帮助。如果一个 AI agent 一次做了五处改动然后坏了，那些改动在单独提交里，更容易定位哪个提交导致问题。如果全在一个叫"AI 改动"的巨型提交里，祝你好运！所以我自律：完成任务，跑测试，提交。这也和前面拆小块的建议契合——每块最终成为自己的提交或 PR。
最后，别怕用分支或 worktree 隔离 AI 实验。我采用的一个高级工作流（受 Jesse Vincent 等人启发）是为新功能或子项目开一个全新的 git worktree。这让你能在同一个仓库并行跑多个 AI 编码会话而不互相干扰，之后合并改动。有点像给每个 AI 任务一个自己的沙箱分支。如果一个实验失败，丢掉那个 worktree，主分支什么都没丢。如果成功，合并进去。这个方法在比如"让 AI 实现功能 A，同时我（或另一个 AI）做功能 B"时至关重要。版本控制正是让这种协作成为可能的东西。一句话：频繁提交、用分支组织工作、拥抱 git，把它作为让 AI 生成的改动可控可逆的控制机制。
用规则和示例定制 AI 的行为
通过提供风格指南、示例甚至"规则文件"来引导你的 AI 助手——一点前置调校换来好得多的输出。
我学到的一件事是，你不必接受 AI 的默认风格或方法——你可以通过给指南来极大影响它。比如，我有一个定期更新的 CLAUDE.md 文件，包含 Claude（Anthropic 的模型）要遵循的流程规则和偏好（用 Gemini CLI 时类似的有 GEMINI.md）。内容包括"用我们项目的风格写代码、遵守我们的 lint 规则、不要用某些函数、偏好函数式而非 OOP"等。开始会话时，我把这个文件喂给 Claude 让它对齐我们的约定。让模型"保持在轨道上"的效果惊人地好——它减少了 AI 脱稿或引入我们不想要模式的倾向。
即使没有花哨的规则文件，你也可以用自定义指令或系统提示设定基调。GitHub Copilot 和 Cursor 都引入了让你为项目配置 AI 行为的特性。我利用过这个——写一小段关于我们编码风格的文字，比如"用 4 空格缩进、React 里避免箭头函数、变量名要描述性、代码要过 ESLint"。有了这些指令，AI 的建议会贴合人类队友可能写的东西。Ben Congdon 提到他惊讶于很少人用 Copilot 的自定义指令，考虑到它多有效——通过提前提供示例和偏好，他能引导 AI 输出匹配团队习语的代码。我附议：花时间教 AI 你的期望。
另一个强大技巧是提供行内示例——你想要的输出格式或方法。如果我想让 AI 以非常特定的方式写一个函数，我可能先给它看代码库里已有的相似函数："这是我们实现 X 的方式，对 Y 用类似的方法。"如果我想要某种注释风格，我会自己写一条注释，让 AI 按那种风格继续。本质上，用模式引导模型。LLM 擅长模仿——给它们一两个示例，它们就会沿着那个方向继续。
社区也想出了创造性的"规则集"来驯服 LLM 行为。你可能听说过 "Big Daddy" 规则，或在提示里加"不许幻觉/不许欺骗"条款。这些基本是提醒 AI 诚实、不要过度编造不存在的代码的技巧。比如，我有时在提示前加："如果你不确定某事或代码库上下文缺失，要求澄清而不是编造答案。"这减少幻觉。我用另一个规则："修 bug 时总是在注释里简短解释你的推理。"这样 AI 生成修复时，也会留下"// Fixed: 改了 X 为 Y 以防 Z（按规格）"这样的注释。对后续审查超有用。
总结：别把 AI 当黑盒——调校它。通过配置系统指令、分享项目文档、写下明确规则，你把 AI 变成团队里更专业的开发者。类似给新人入职：你会给他们风格指南和一些入门提示，对吧？对你的 AI 结对程序员也一样。投资回报巨大：你得到需要更少调整、和你的代码库更顺滑集成的输出。
【未完，请看评论区】
经典软件工程纪律在 AI Coding 时更重要了。
《我 2026 年的 LLM 编码工作流》
My LLM coding workflow going into 2026
AI 编程助手在 2025 年成了游戏规则改变者，但有效驾驭它们需要技巧和结构。这些工具极大地提升了 LLM 对真实编码能做的事，很多开发者（包括我）都拥抱了它们。在 Anthropic，工程师如此重度采用 Claude Code，以至于今天 Claude Code 约 90% 的代码是它自己写的。然而，用 LLM 编程不是一个按钮魔法体验——它"困难且反直觉"，要拿到好结果需要学习新的模式。批判性思维仍然是关键。经过一年多项目，我收敛到一个和许多有经验开发者正在发现的工作流相似的东西：把 LLM 当作一个强大的结对程序员，它需要清晰的方向、上下文和监督，而不是自主判断。
在这篇文章里，我会分享 2026 年我如何规划、编码和与 AI 协作，提炼我自己经验和社区集体学习的技巧与最佳实践。这是一种更自律的"AI 辅助工程"方法——激进地利用 AI，同时对产出的软件保持问责。
从清晰的计划开始（先规格后代码）
别把愿望直接扔给 LLM——先定义问题、规划解决方案。
一个常见错误是带着模糊提示直接进入代码生成。我的工作流里（也是很多其他人的），第一步是和 AI 一起头脑风暴详细规格，然后列出逐步计划，然后才写任何实际代码。对新项目，我会描述想法，让 LLM 迭代地向我提问，直到我们把需求和边界情况都厘清。最后，我们把所有内容编译成一份完整的 spec.md——包含需求、架构决策、数据模型，甚至测试策略。这份规格构成开发的基础。
接下来，我把规格喂给一个带推理能力的模型，提示它生成项目计划：把实现拆成合乎逻辑的小任务或里程碑。AI 基本是在帮我做一次迷你"设计文档"或项目计划。我经常迭代这份计划——编辑、让 AI 批评或细化——直到它连贯完整。然后我才开始编码。这笔前置投入感觉慢，但回报巨大。就像 Les Orchard 说的，这等于做一次"15 分钟的瀑布"——一个快速的结构化规划阶段，让后面的编码顺畅得多。
有清晰的规格和计划意味着，当我们放出代码生成时，人和 LLM 都确切知道我们在构建什么、为什么。一句话：先规划逼着你和 AI 对齐，防止浪费循环。很多人想跳过这步，但有经验的 LLM 开发者现在把扎实的规格/计划当作工作流的基石。
把工作拆成小的迭代块
范围管理就是一切——喂给 LLM 可管理的任务，而不是一次整个代码库。
我学到的一个关键教训是避免向 AI 要大型整体输出。相反，我们把项目拆成迭代步骤或工单，一个一个地攻克。这镜像了良好的软件工程实践，但有人在循环里时它更重要。LLM 在收到聚焦提示时表现最好：一次实现一个函数、修一个 bug、加一个功能。比如规划之后，我会提示代码生成模型："好，让我们实现计划的第 1 步"。我们编码、测试，然后进入第 2 步，如此类推。每块小到 AI 能在上下文里处理、你能理解它产出的代码。
这个方法防模型脱轨。如果你一次要太多，它很可能困惑或产出难解的"一团乱"。有开发者报告，当他们试图让 LLM 生成应用的大块时，结果是不一致和重复——"像 10 个开发者在没互相沟通的情况下工作"。我感受过那种痛；解法是停下、后退、把问题拆成更小的块。每轮迭代，我们带上已构建内容的上下文，增量添加。这也很好地配合测试驱动开发（TDD）——我们可以边走边为每块写或生成测试。
几个编码 agent 工具现在显式支持这种分块工作流。比如，我经常生成一个结构化的"提示计划"文件，包含每个任务的提示序列，这样 Cursor 之类的工具能逐个执行。关键点是避免巨大的跳跃。通过小循环迭代，我们大幅降低灾难性错误的概率，并能快速纠偏。LLM 擅长快速、受限的任务——利用这一点。
提供充分的上下文和指导
LLM 的好赖取决于你提供的上下文——展示它们相关代码、文档和约束。
在代码库上工作时，我确保把 AI 表现好所需的全部信息喂给它：它要修改或引用的代码、项目的技术约束、以及任何已知陷阱或首选方法。现代工具有帮助：Anthropic 的 Claude 可以在"Projects"模式下把整个 GitHub 仓库导入上下文；Cursor 或 Copilot 这类 IDE 助手自动把打开的文件包含进提示。但我经常更进一步——如果怀疑模型没有某些内容，我会用 MCP（如 Context7）或手动把代码库或 API 文档的重要部分复制进对话。
专家 LLM 用户强调这个"上下文打包"步骤。比如做一次"大脑倾倒"——把模型在编码前应该知道的一切倒出来，包括：高层目标和不变式、好解决方案的例子、以及要避免的方法的警告。如果我让 AI 实现一个棘手的方案，我可能会告诉它哪些 naive 方案太慢，或者从别处提供一个参考实现。如果我用一个冷门库或全新 API，我会把官方文档或 README 贴进去，这样 AI 不是盲目飞行。所有这些前置上下文都大幅提升输出质量，因为模型不是在猜——事实和约束就在它面前。
现在有工具可以自动化上下文打包。我试过 gitingest 或 repo2txt 这类工具，它们把你的代码库相关部分"倾倒"成一个文本文件给 LLM 读。处理大项目时它们是救星——生成一个关键源文件的 output.txt 包，让模型消化它。原则是：别让 AI 在残缺信息上运行。如果修一个 bug 需要理解四个不同模块，就展示那四个模块。是的，我们必须注意 token 上限，但当前前沿模型有相当大的上下文窗口。明智地使用它们。我经常只选任务相关的那部分代码，并明确告诉 AI 哪些不要关注（省 token）。
我觉得 Claude Skills 有潜力，因为它们把以前脆弱、重复的提示变成持久可复用的东西——把指令、脚本和领域专长打包成模块化能力，工具能在请求匹配时自动应用。这意味着比通用提示更可靠、更上下文感知的结果，从一次性交互转向编码可重复程序和团队知识的工作流。社区策展的 Skills 集合不少，但我最喜欢的例子是 frontend-design skill——它能"终结"LLM 生成 UI 里泛滥的紫色设计美学。在更多工具官方支持 Skills 之前，也有变通方案。
最后，用提示里的注释和规则引导 AI。我可能在一个代码片段前写："这是 X 的当前实现。我们需要扩展它做 Y，但小心别破坏 Z。"这些小提示大有帮助。LLM 是字面主义者——它们会遵循指令，所以给它们详细、有上下文的指令。通过主动提供上下文和指导，我们最小化幻觉和离谱建议，得到契合项目需求的代码。
选对模型（需要时用多个）
不是所有编码 LLM 都平等——有意图地挑选工具，别怕中途换模型。
2025 年我们被各种能力强大的编码 LLM 宠坏了。我工作流的一部分是为每个任务选择最适合的模型或服务。有时甚至并行试两个或更多 LLM，交叉检查它们如何不同地处理同一个问题。
每个模型都有自己的"性格"。关键是：如果一个模型卡住或产出平庸，换一个试试。我真的把同一个提示从一个聊天复制到另一个服务，看它能不能处理得更好。这种"模型抢椅子"能在你撞上模型盲区时救你。
另外，确保你用的是最好的版本。如果可以，用最新的"pro"级模型——因为质量很重要。是的，通常意味着付费，但生产力收益能证明它。最终，选那个"气质"和你合拍的 AI 结对程序员。我认识有人偏爱某个模型只是因为喜欢它回复的感觉。那完全合理——当你基本在和 AI 持续对话时，UX 和语气有影响。
我个人现在很多编码工作倾向于 Gemini（坦白：我在 Google 做 Gemini，自然更熟悉），因为交互感觉更自然，常常第一次就能理解我的请求。但需要时我会毫不犹豫换模型；有时第二意见能帮解决方案浮现。总结：用最适合工作的工具，记住你手头有一整支 AI 兵工厂。
在整个生命周期利用 AI 编码
命令行出现了新的 AI agent。Claude Code、OpenAI 的 Codex CLI 和 Google 的 Gemini CLI 都是 CLI 工具，你在项目目录里直接和它们对话——它们能读文件、跑测试、甚至多步修问题。我也用过 Google 的 Jules 和 GitHub 的 Copilot Agent——这些是异步编码 agent，实际上把你的仓库克隆进云 VM，在后台工作（写测试、修 bug，然后为你开 PR）。有点诡异：你发出"重构支付模块做 X"的命令，一会儿之后你收到一个带代码改动和通过测试的 pull request。我们真的活在未来。
话虽如此，这些工具不是万无一失的，你必须理解它们的局限。它们加速编码的机械部分——生成样板、应用重复改动、自动跑测试——但依然非常需要你的指导。比如，当用 Claude 或 Copilot 这类 agent 实现东西时，我经常把前面步骤的计划或待办列表提供给它，让它知道确切的任务序列。如果 agent 支持，我会在执行前把 spec.md 或 plan.md 加载进上下文。这让它保持在轨道上。
我们还没到让 AI agent 无人看管地编码整个功能并期待完美结果的阶段。相反，我以监督的方式使用这些工具：我让它们生成甚至运行代码，但盯着每一步，看到不对劲随时介入。还有 Conductor 之类的编排工具，让你在不同任务上并行跑多个 agent（本质上是规模化 AI 帮助的方式）——一些工程师在实验一次跑 3-4 个 agent 处理不同功能。我试过这种"大规模并行"方法；它能高效完成很多事，但监视多个 AI 线程也很费神！多数情况下，我一次只用一个主 agent，也许再加一个次要的做审查。
记住，这些是强力工具——你仍然控制扳机、引导结果。
保持人在循环——验证、测试、审查一切
AI 会很乐意产出看起来可信的代码，但你对质量负责——总是彻底审查和测试。我的一条基本原则是绝不盲目信任 LLM 的输出。就像 Simon Willison 精辟说的，把 LLM 结对程序员想成"过度自信、容易犯错"。它带着完全的自信写代码——包括 bug 或胡说——而且不会告诉你哪里不对，除非你抓到。所以我对待每一段 AI 生成的片段，都像来自初级开发者的代码：读一遍、跑一遍、按需测试。你必须测试它写的东西——跑单元测试，或手动演练功能，确保它真的做了它声称的事。
事实上，我把测试织进工作流本身。我早期的规划阶段经常包括为每步生成测试列表或测试计划。如果用 Claude Code 这类工具，我会指示它在实现任务后跑测试套件，有失败就调试。这种紧密反馈循环（写代码→跑测试→修复）正是 AI 擅长的——只要有测试存在。那些从编码 agent 获益最多的人，往往是有强大测试实践的人。Claude 这样的 agent 能在好测试套件作为安全网时"飞"过项目。没有测试，agent 可能心安理得地假设一切正常（"当然，都好！"）而实际上它已经弄坏了几处。所以，投资测试——它放大 AI 的用处和你对结果的信心。
即使超越自动化测试，做代码审查——人工和 AI 辅助都做。我例行暂停，逐行审查已生成的代码。有时我会开第二个 AI 会话（或不同模型），让它批评或审查第一个产出的代码。比如，我可能让 Claude 写代码，然后问 Gemini："你能审查这个函数有没有错误或改进吗？"这能抓到微妙问题。关键是别因为代码是 AI 写的就跳过审查。如果有的话，AI 写的代码需要额外审查，因为它有时表面上令人信服，却藏着人类不会立刻注意的缺陷。
我也用 Chrome DevTools MCP——和上一个团队一起做的——用于调试和质量循环，弥合静态代码分析和实时浏览器执行之间的鸿沟。它"给 agent 一双眼睛"，让它直接访问浏览器能看到的、检查 DOM、拿丰富的性能追踪、控制台日志或网络追踪。这个集成消除了手动上下文切换的摩擦，允许通过 LLM 直接做自动化 UI 测试。bug 可以基于真实运行时数据被高精度诊断和修复。
跳过人工监督的严重后果有据可查。一个重度依赖 AI 生成赶工项目的开发者，把结果描述为不一致的乱摊子——重复逻辑、错配的方法名、没有连贯架构。他意识到自己一直在"建、建、建"，没有退后一步真正看看 AI 编织出了什么。解法是一次痛苦的返工，以及再也不让事情失控到那种地步的誓言。我记住了。无论我用多少 AI，我仍然是负责的工程师。
实际操作上，这意味着只有在我理解代码之后才合并或发布。如果 AI 生成的东西绕来绕去，我会让它加注释解释，或者用更简单的术语重写。如果有什么感觉不对，我深挖——就像人类同事贡献了有危险信号的代码那样。
一切都是心态：LLM 是助手，不是自动可靠的编码者。我是资深开发者；LLM 是来加速我的，不是取代我的判断。保持这种姿态不仅产出更好的代码，也保护你自己作为开发者的成长。一句话：保持警觉，多测试，常审查。归根结底这还是你的代码库。
频繁提交，用版本控制当安全网。绝不提交你解释不了的代码。
频繁提交是你的存档点——它们让你撤销 AI 的失手、理解改动。
当和一个能快速生成大量代码的 AI 工作时，事情很容易跑偏。我通过采纳超细粒度的版本控制习惯来缓解。我早提交、频繁提交，甚至比手工编码时更频繁。每完成一个小任务或每次成功的自动编辑，我就带着清晰消息做一次 git 提交。这样，如果 AI 的下一个建议引入 bug 或混乱改动，我有一个最近的检查点可以回退（或 cherry-pick），不会丢失几小时工作。一位实践者把它比作"游戏里的存档点"——如果 LLM 会话翻车，你总能回滚到最后一个稳定提交。这条建议非常有用。当你知道必要时可以用 git reset 撤销时，大胆的 AI 重构实验压力小得多。
正确的版本控制在和 AI 协作时也有帮助。既然不能指望 AI 记住它做的一切（上下文窗口限制等），git 历史就成了宝贵的日志。我经常扫最近的提交来给 AI（或自己）简报改了什么。事实上，LLM 自己能利用你的提交历史——我把 git diff 或提交日志贴进提示，让 AI 知道哪些代码是新的、之前状态是什么。有趣的是，LLM 非常擅长解析 diff 和使用 git bisect 这类工具找 bug 是哪里引入的。它们遍历提交历史有无限的耐心，能增强你的调试。但这只有在你一开始就有整洁的提交历史时才有效。
另一个好处：带好消息的小提交基本上记录了开发过程，做代码审查（AI 或人类）时有帮助。如果一个 AI agent 一次做了五处改动然后坏了，那些改动在单独提交里，更容易定位哪个提交导致问题。如果全在一个叫"AI 改动"的巨型提交里，祝你好运！所以我自律：完成任务，跑测试，提交。这也和前面拆小块的建议契合——每块最终成为自己的提交或 PR。
最后，别怕用分支或 worktree 隔离 AI 实验。我采用的一个高级工作流（受 Jesse Vincent 等人启发）是为新功能或子项目开一个全新的 git worktree。这让你能在同一个仓库并行跑多个 AI 编码会话而不互相干扰，之后合并改动。有点像给每个 AI 任务一个自己的沙箱分支。如果一个实验失败，丢掉那个 worktree，主分支什么都没丢。如果成功，合并进去。这个方法在比如"让 AI 实现功能 A，同时我（或另一个 AI）做功能 B"时至关重要。版本控制正是让这种协作成为可能的东西。一句话：频繁提交、用分支组织工作、拥抱 git，把它作为让 AI 生成的改动可控可逆的控制机制。
用规则和示例定制 AI 的行为
通过提供风格指南、示例甚至"规则文件"来引导你的 AI 助手——一点前置调校换来好得多的输出。
我学到的一件事是，你不必接受 AI 的默认风格或方法——你可以通过给指南来极大影响它。比如，我有一个定期更新的 CLAUDE.md 文件，包含 Claude（Anthropic 的模型）要遵循的流程规则和偏好（用 Gemini CLI 时类似的有 GEMINI.md）。内容包括"用我们项目的风格写代码、遵守我们的 lint 规则、不要用某些函数、偏好函数式而非 OOP"等。开始会话时，我把这个文件喂给 Claude 让它对齐我们的约定。让模型"保持在轨道上"的效果惊人地好——它减少了 AI 脱稿或引入我们不想要模式的倾向。
即使没有花哨的规则文件，你也可以用自定义指令或系统提示设定基调。GitHub Copilot 和 Cursor 都引入了让你为项目配置 AI 行为的特性。我利用过这个——写一小段关于我们编码风格的文字，比如"用 4 空格缩进、React 里避免箭头函数、变量名要描述性、代码要过 ESLint"。有了这些指令，AI 的建议会贴合人类队友可能写的东西。Ben Congdon 提到他惊讶于很少人用 Copilot 的自定义指令，考虑到它多有效——通过提前提供示例和偏好，他能引导 AI 输出匹配团队习语的代码。我附议：花时间教 AI 你的期望。
另一个强大技巧是提供行内示例——你想要的输出格式或方法。如果我想让 AI 以非常特定的方式写一个函数，我可能先给它看代码库里已有的相似函数："这是我们实现 X 的方式，对 Y 用类似的方法。"如果我想要某种注释风格，我会自己写一条注释，让 AI 按那种风格继续。本质上，用模式引导模型。LLM 擅长模仿——给它们一两个示例，它们就会沿着那个方向继续。
社区也想出了创造性的"规则集"来驯服 LLM 行为。你可能听说过 "Big Daddy" 规则，或在提示里加"不许幻觉/不许欺骗"条款。这些基本是提醒 AI 诚实、不要过度编造不存在的代码的技巧。比如，我有时在提示前加："如果你不确定某事或代码库上下文缺失，要求澄清而不是编造答案。"这减少幻觉。我用另一个规则："修 bug 时总是在注释里简短解释你的推理。"这样 AI 生成修复时，也会留下"// Fixed: 改了 X 为 Y 以防 Z（按规格）"这样的注释。对后续审查超有用。
总结：别把 AI 当黑盒——调校它。通过配置系统指令、分享项目文档、写下明确规则，你把 AI 变成团队里更专业的开发者。类似给新人入职：你会给他们风格指南和一些入门提示，对吧？对你的 AI 结对程序员也一样。投资回报巨大：你得到需要更少调整、和你的代码库更顺滑集成的输出。
【未完，请看评论区】
42 228