> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# AI编程无废话指南(2026)
- URL: https://www.hubwiz.com/blog/the-no-nonsense-guide-to-ai-coding/
- Published: 2026-01-24T18:16:11.000Z
- Updated: 2026-01-24T18:16:11.000Z
- Description: 外面有一个完整的生态系统在向你推销魔法技巧。特殊循环和代理群体。品牌化的方法论。带缩写的框架。带有戏剧性声明的终端输出截图。
- Author: admin
- Tags: AI, VIBE CODING, #Import 2026-10-14 14:41

忘记缩写。忘记循环，兄弟们。忘记上周在 X 上发布的任何框架。

看在上帝的份上，停止关注和引用 AI 兄弟们！

有效使用 AI 编程代理的基本原理并不新鲜。

它们是让开发人员在 AI 之前就有效的同样东西。好的规格。清晰的文档。审查。正确的堆栈。适当的部署。决策的历史以及为什么做出这些决策。

现在的不同是这些东西更重要，而不是更不重要。因为当你把工作交给没有它们的代理时，代理会填补空白。有时它做得很好。有时不是——但在大规模上……我们从脚枪变成了脚炮弹。

## 1、AI 兄弟陷阱

外面有一个完整的生态系统在向你推销魔法技巧。特殊循环和代理群体。品牌化的方法论。带缩写的框架。带有戏剧性声明的终端输出截图。

这是开发人员的生产力色情。与 n8n 工作流痴迷者花费更多时间构建自动化而不是做实际工作的陷阱相同。与销售课程的加密兄弟们的能量相同。

模式总是相同。用虚假的信心引诱人们。让他们感觉错过了一个秘密。让他们以某种方式付费，无论是金钱还是时间浪费追逐错误的东西。

它造成的伤害比好处多。人们陷入这些陷阱，为复杂性而追求复杂性而浪费数周。他们对自己的设置进行自我膨胀，而不是发布可工作的软件。他们构建自己不理解也无法维护的复杂系统，并将它们推销为灵丹妙药。

真正起作用的东西不是秘密。它们不新鲜。它们是软件开发的基本原理，应用于新工具。

## 2、不要外包思考

一些开发人员输入"创建这个\[填充东西\]应用程序"并回车。或者"为这个添加身份验证。"当结果与他们头脑中的东西不匹配时，他们感到惊讶。

当你让事情模糊时，代理会做选择。它选择一个堆栈。它决定数据模型。它发明用户流程。它不会审问你。它只是构建一些东西。

代理在这方面越来越好了。现在存在规划模式。代理在开始之前会询问澄清问题的访谈模式。这是很好的进展。但你总是可以通过预先提供必要信息来抢占它。

堆栈选择。用户旅程。数据流。你需要与人类开发人员达成一致的事情，你需要与代理达成一致。

思考是为了你。不是 LLM。

## 3、采取小步骤

把一个大功能切成小块是可以的。事实上，这样更好。

更小的步骤更容易引导。如果代理走向错误的方向，你会及早发现它。你可以在错误复合之前进行调整。

更小的步骤更容易理解。你看到改变了什么。你知道为什么改变。如果需要，你可以向别人解释它。

更小的步骤更容易调试。当某物损坏时，可能原因的表面区域是有限的。

诱惑是给代理一个大任务然后走开。让它过夜烹饪。醒来看到一个完成的功能。有时这有效。通常不会。当它无效时，你留下一堆你没有看到被编写且不完全理解的代码。

把它分解。一次一件。边进行边审查。

## 4、了解你的代码库

不了解你的代码库是一个将到期的负债。

客户问某物如何工作的问题。"我不知道，AI 写的。"这不是一个好答案。

某物在凌晨3点坏了，你接到电话。现在你正在调试从未读过的代码，试图理解你没有做出的决策，追踪你没有设计的逻辑。调查的每一分钟都是你在代码被编写时通过保持接近本可以节省的时间。

当你让代理生成数千行而不理解它们时，你不是在节省时间。你在借用它。利率很高，付款在最糟糕的时刻到期。

保持接近代码。审查生成的内容。确保如果被问到，你可以解释你系统的任何部分。这不是可选的。这是工作。

## 5、大多数会话以计划模式开始

在你让代理编写代码之前，确保你喜欢它的计划。

目标是编写拉取请求，从计划模式开始。与代理来回，直到计划有意义。挑战假设。询问边缘情况。确保方法是你真正想要的。

一旦计划坚实，切换到自动接受模式。好的计划意味着代理通常可以一次性执行。糟糕的计划意味着你正在调试你不理解的生成代码。

你在规划上投入的时间会作为执行中节省的时间回报。前几分钟额外可以节省数小时的清理时间。

## 6、AGENT.md 是你的朋友

你和你团队需要达成一致的每一件事都属于代理可以访问的文档。

拆分你的配置。有一个带有你自己怪癖的个人设置文件。总是运行健全性检查。以某种格式提交。不需要团队对齐但使你的工作流程更顺畅的事情。

然后有一个提交到仓库的团队 AGENT.md 或 CLAUDE.md。编码协议。系统设计决策。先前对齐的选择。这是保持代理在团队中一致的共享上下文。

关键习惯：任何时候看到代理做错了什么，就添加它到共享文件。整个团队都应该贡献。这随时间复合。代理从每个错误中学习，但只有在你记录它们时。

在代码审查期间，当相关时，将更新共享文档作为 PR 的一部分。这是复合工程。每个修复使下一个会话更好。

对于棕地项目，用 /init 开始推断堆栈。让代理在你开始要求添加之前理解已经存在的东西。

## 7、给代理一种验证其工作的方法

这可能是获得好结果的最重要的事情。

如果代理有反馈循环，它将提高最终输出质量的 2–3 倍。没有验证，代理在猜测。有验证时，它可以迭代直到事物真正工作。

验证看起来像什么取决于你的领域：

对于后端代码，它可能是运行测试套件或执行确认预期行为的 bash 命令。

对于前端工作，它可能是打开浏览器、测试 UI，并迭代直到 UX 感觉正确。

对于移动端，它可能是在模拟器中运行应用。

形式不如存在重要。确保代理可以检查它自己的工作。投资使其坚如磐石。这是看起来正确的代码和实际正确的代码之间的区别。

## 8、手动添加测试……或根本不

![](https://www.hubwiz.com/blog/content/images/2026/01/image-735.png)

如果你要有测试，让它们不可变。这比听起来更难，但这是测试真正保护你的唯一方式。

代理需要运行测试。它需要读取输出、检查堆栈跟踪、分析什么失败了以及为什么。但它永远不应该重写测试来使它们通过。

这里是如何强制执行它：

**在仓库级别保护测试文件。** 添加 CODEOWNERS 规则，只有特定的人可以批准对测试文件的更改。要求对任何触及测试路径的内容进行拉取请求审查。使测试更改有意和可见。

**让代理运行测试，而不是编辑它们。** 完全读取访问。完全执行权限。没有写入访问。代理通过控制台输出和结构化报告推理失败，而不是通过修改断言。

**在 CI 中强制不可变性。** 添加一个检查，如果测试文件更改则构建失败。将分支与基础比较。如果测试路径下的任何文件被修改，管道以错误退出。这将"不要更改测试"从指导原则变为不变量。

**使用预提交钩子作为早期捕获。** 可选但有用。它们防止测试文件被批量更改或自动格式化卷入。

**定义明确的异常路径。** 测试在现实生活中确实会改变。新功能需要新测试。但要明确它。要求标签。需要人工批准。代理可能建议补丁但绝不能应用它。

实现留给人类。

我不喜欢 TDD，我有一个要分享的大宠物 peeve。我将在未来的文章中强调为什么和什么。

## 6、使用钩子进行格式化和验证

PostToolUse 钩子处理机械清理。代理通常生成格式良好的代码，但钩子处理最后 10% 以避免 CI 中稍后的格式错误。

生成后钩子可以在代理完成编写代码后运行测试。反馈回流。但测试本身在整个过程中保持未被触及。

这给你没有代理"修复"测试以匹配损坏代码风险的反馈循环。

## 7、并行运行多个会话

![](https://www.hubwiz.com/blog/content/images/2026/01/image-736.png)

一个代理是有用的。五个代理在问题的不同部分工作是一个力量倍增器。

运行多个带有不同会话的终端选项卡。给它们编号。使用系统通知知道会话何时需要输入。根据需要在本地和 Web 会话之间切换。早上从手机启动会话，稍后检查它们。使用 git 工作树。

这是吞吐量的实际解锁。不是魔法提示。不是特殊框架。只是跨独立任务的并行主义。但不要过度。你只能在几个任务上保持良好专注，并考虑自己的健康。没有必要一直运行 5–10 个代理。

## 8、对重复工作流使用斜杠命令

你一天多次做的任何工作流都应该变成斜杠命令。

提交、推送和打开 PR。运行标准测试套件。检查部署状态。无论你的内部循环看起来像什么，自动化它。

命令可以使用内联 bash 预计算信息，这使它们运行快速并避免与模型来回。它们被检查到 git 并存在于命令文件夹中。团队共享它们。

这使你免于重复提示。这也意味着代理可以使用这些工作流，保持一致性。

## 9、对常见工作流使用子代理

子代理自动化你对大多数 PR 所做的工作流。

一个在代理完成后进行清理的代码简化器。一个带有详细端到端测试指令的 verify-app 代理。无论你发现自己在会话中重复的什么模式。

将子代理视为专用工具。主代理编排。子代理处理它们被调整的特定工作，并保持你的主要上下文干净。

## 10、关注你的运行

你不能微观管理代理。这违背了目的。但也不要完全走开。

偶尔窥视。你正在寻找什么：连续错误过多，持续失败的工具调用，代理在同一问题上没有进展地旋转。

这些是事情偏离轨道的迹象。及早发现比回到一团糟更好。

对于非常长时间运行的任务，提示代理在完成时用后台代理验证其工作。或者使用停止钩子更确定地做这件事。目标是确认工作真正成功，不仅仅是代理停止了。

## 11、预允许安全命令

而不是完全跳过权限，预先允许你知道在你的环境中安全的特定命令。

使用 /permissions 设置这些。大多数可以检查到设置中并与团队共享。这避免了不必要的权限提示而不打开一切。

代理应该使用你现有的工具。通过 MCP 使用 Slack。通过 CLI 进行数据库查询。来自监控的错误日志。将配置检查到仓库中，以便整个团队都有访问权限。

![](https://www.hubwiz.com/blog/content/images/2026/01/image-737.png)

## 12、氛围编码 vs 代理编码

氛围编码是不关心细节。你松散地描述你想要什么，代理构建某物，你基于出现的内容迭代。这很棒。

代理编码是更关心结果。你提供上下文。你定义约束。你维护测试。你审查生成的内容。

一个不比另一个更好。它们适用于不同情况。

氛围编码在你需要快速测试某物时有效。当你完全从绿野开始并探索什么可能时。当搞错的成本很低时。

但要小心。氛围编码的应用可以变成更大的东西。当那发生时，或即将发生时，暂停。运行代码简化。在你建造更多房间之前把房子整理好。

## 13、模型选择重要

为任务使用最好的可用模型。更大和更慢通常击败更小和更快，因为你必须更少地引导它，并且它更好地处理工具使用。如果可以，使用 Claude Opus 4.5 并有耐心。

反直觉的结果：一个第一次就做对的较慢模型比你必须重复纠正的快速模型更快。

## 14、广度而非专业化

这里有与 AI 兄弟建议相反的东西。

而不是专精于一个框架或一种方法，尽可能广泛地熟练是有帮助的。这样你可以对重要的事情有监督。你可以评估代理的选择在整个堆栈中是否有意义，而不仅仅是在你很了解的窄片中。

从 AI 编程代理获得最好结果的人不是学习了一种魔法技巧的人。他们是那些已经广泛理解软件开发并现在拥有一个移动更快的工具的人。

## 15、重置

如果你一直在做循环事情、框架事情、缩写事情，而它不起作用，这就是明天早上要做的事情。

退后一步。制作仓库的副本。移除 ./claude 文件夹或 AGENT.md 或任何规则文件已累积。重新开始。

调查实际建造了什么。运行 /init。评估堆栈选择是否是正确选择。在需要时调整。

或者，如果你在项目中不太深入，完全重新开始。这不像以前那么痛苦。代理可以快速重建。重新开始可能是你项目的最佳事情。记录高级功能——这次逐步通过它。

当你看到代理生成数千行代码时，沉没成本谬误更强烈地打击你。但你不理解的生成代码不是资产。它是负债。

## 16、心态

如果你正在阅读这个并感觉有点被点名，这里是重新框架。

将代理视为一个非常渴望和勤奋的同事。它想要帮助。它会努力工作。它会快速工作。但它需要方向。它需要上下文。它需要你告诉它好的样子。

你不会给新员工一个模糊的任务然后消失八小时。你会解释背景。你会指出相关文档。你会检查。你会回答问题。你会在其发布前审查他们的工作。

这里同样的事情。代理是有能力的。但有能力不等于自主。有能力意味着如果设置为成功，它可以做很棒的工作。那是你的工作。

获得最好结果的开发人员不是拥有最花哨设置的人。他们是那些保持参与的人。谁理解他们的代码库。谁提供清晰的上下文。谁审查产生的内容。谁将代理视为协作者，而不是思考的替代品。

就是这样。不需要魔法。

## 17、结束语

没有一种使用 AI 编程代理的正确方法。每个人以不同方式使用它们。这是有意的。

但起作用的模式共享共同特征：

在开始之前提供上下文。在执行之前规划。记录重要的事情并保持更新。给代理验证其工作的方法。使测试不可变。使用钩子进行格式化和验证。并行运行会话。自动化重复工作流。保持足够监督以及早发现问题。知道何时氛围编码和何时关心。广泛熟练以便你可以评估代理产生什么。

代理是快的。你提供方向。

就是这样。不需要缩写。它不是火箭手术。

![](https://www.hubwiz.com/blog/content/images/2026/01/image-739.png)

...它不是……

*什么对你有效？我对特定工作流感兴趣，而不是品牌化方法论。*

---

原文链接: [The No-Nonsense Guide to AI-Assisted Coding in 2026](https://kotrotsos.medium.com/the-no-nonsense-guide-to-ai-assisted-coding-in-2026-9e3c961be244?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处