AI_Coding日志_通用技巧
这一篇内容偏技术但也没那么深入，在理解了 Vibe Coding 与 AI Coding 的区别，以及 Vibe Coding 的局限性 之后，浅浅学习一些技术没有坏处，也是大势所趋。
我认为对于非技术背景人士，先从不那么技术的内容开始，把 AI 工具用起来，建立一种"原来我也可以"的正反馈，从而激励自己继续深入学下去。
本文面向非专业人士编写，但仍会浅尝辄止地分享一些 AI Coding 偏通识的技术内容，这些也是 AI Coding 最核心的几个内容。
有两个点需要明确：
- 在上一篇日志中我已经表达过我一直秉持的观点：想彻底融入并长期使用 AI Coding，技术是必须掌握的，只是深浅的问题
- AI Coding 日志系列的文章将始终使用"AI Coding"而不是 Vibe Coding 的概念，并且不会介绍任何纯 Vibe Coding 的工具
1. 一、AI 工具形态与选择
我已经在 上一篇日志 中分享过一些工具的选择策略，这里则补充另一个选择工具的角度：交互方式。
当前的 AI Coding 工具按照交互方式，大体上分为网页、IDE 插件与命令行三种。
网页是大家最熟悉的，我们打开 Chat 聊天框就能让它写代码，粘贴到我们的文件，保存，执行即可。
IDE 是集成开发环境的意思，是程序员的工作台，最核心的办公工具，犹如原型图工具之于产品经理，Figma 之于交互与视觉设计师。IDE 具有平台的特点，其中的"集成"表示它可以集成其他的工具，以便尽可能无缝地在一个界面中完成工作。
知名工具如 Cursor、Trae、Qoder、Codebuddy 等是以 IDE 的形态出现，上手并不困难，因为最常用的功能只有那么几个。
图 1：IDE（Trae）界面——左侧代码导航、中间代码编辑与界面预览、右侧与 AI Coding Agent 对话、底部内置命令行
命令行（Command Line）或 CLI（Command Line Interface），就是那个黑底绿字的工具，它是一种与计算机交互的方式。
图 2：命令行（CLI）界面示例
IDE 和电脑上其他可视化软件一样属于"图形界面"，在 Windows 这样的图形界面操作系统出现以前，人们使用电脑的方式就是命令行。图形界面使得电脑进入千家万户，命令行最初只是给极少数专业人员使用。时至今日，命令行仍然占据一席之地，在系统底层控制、追求效率与精确性、自动化与远程操作的场景中，命令行仍然具有不可替代性。
OpenAI Codex、Claude Code、Gemini 都支持命令行工具，并且被极客群体疯狂追捧。
图形化界面的 IDE 与命令行相比，有一些独占功能，如 IDE 中通常都有预览功能——在开发一个前端页面的时候我们离不开实时预览，在 IDE 内部实时预览并利用 IDE 自身的截取元素的功能来添加至上下文，这是命令行自身不具备的能力。另外还有会话管理、集成其他插件的功能。
对于非技术背景的人士，开发一次性或者简单的工具，使用网页版；作为独立开发者，请使用图形化界面的 IDE；命令行工具，应当作为辅助工具，处理棘手 bug、性能优化等等。
2. 二、上下文
上下文是 AI Coding 的核心，它是直接影响输出结果质量的环节。
2.1. Agent Manifest
如果把代码类 Agent 比作人类助手的话，我们雇佣一个助手辅助自己，最好整理一个文档，帮助他快速熟悉工作——在公司里我们自己带人的时候这种事不会陌生。
Agent Manifest 是一份写给代码 Agent 的工作熟悉文档，我们需要告诉他：
- 项目简介
- 代码风格 / 约定 / 规范
- 工具 / 脚本 / 命令补充
- 安全 / 警告 / 特殊行为
- 交互 / 覆盖 / 冲突处理
图 3：AGENTS.md 文件示例——Setup commands（安装/启动/测试命令）与 Code style（代码风格约定）两段配置
这类文件均使用 Markdown 格式，没有内容的限定，我们可以自由扩展。以 Codex CLI 为例，下面是 Agent Manifest 文件的工作原理：
我们在一个空目录下创建一个名为 AGENTS.md 的文件，在里面写好自己的项目介绍，以及其他自定义的内容，然后启动 Codex CLI 就可以开始 coding 了。在这个过程中，Codex CLI 会在每一次请求中读取这个文件的内容，确保自己的响应符合要求。
必须说明的是，不同公司的产品，对于 Agent Manifest 文件的命名、存放位置是有差异的。
对于命名，Claude Code 的说明文件叫做 CLAUDE.md[1]，而 Gemini 则叫做 GEMINI.md[2]，而 Codex CLI 叫做 AGENTS.md。人们通常会使用多个 Coding Agent，对于这种差异性自然会吐槽，于是就诞生了试图统一各家工具的开源标准：AGENTS.md[3]，目前 Codex CLI 和 Gemini 都支持这个标准。
对于国产工具来说，像 Trae 整得比较特别，它支持两种级别的 Agent Manifest：项目级别和用户级别。项目级别就是在每个项目下会有这样的一个配置文件，让 Agent 针对不同项目遵循不同的要求；用户级别，则是跟随这个账号，这个账号下所有的项目共享这个说明文件。
在我看来，你可以创新，但你应当兼容开源标准，为用户使用方便，而不是太自以为是地认为自己的设计巧妙。
2.2. 会话
会话在 Chat/Agent 工具中都是一种上下文的隔离功能，我们在同一个会话中讨论同一个主题，在不同会话中讨论不同的主题，防止不同信息对模型造成干扰。
在同一个会话中与 Agent 对话，上下文会随时间推移越来越长，最终会超出模型自身的限制，此时就不得不换一个新的会话。有些优化不好的 Coding 工具，在会话内容过多的时候，会出现响应速度慢、逻辑变得混乱、效果下降的情况，这个时候也需要及时更换新的会话。
总体来说，什么时候建议切换到新的会话：
- 会话中的内容超长导致工具效果下降
- 需要解决一个全新的问题，且不想影响当前的进展。比如我们在一个会话中迭代 A 模块的功能，在另一个会话中去修复 B 模块的 bug——我们当然是可以并行 Coding 的
Codex CLI 提供一个压缩上下文的功能，并给出当前上下文剩余的 Token 百分比——这个剩余 Token 百分比显示了这个会话所能承载的上下文的剩余容量，当它达到比较低的一个百分比时，执行上下文压缩功能，Codex 会最大限度总结当前已有对话历史中的重要信息，并去掉其余内容，从而释放出容量以继续当前会话。
这个功能极为好用。
2.3. 不必废话
用好上下文，我们能少打很多字。这取决于我们能够判断出，当前 Coding 工具已经理解了我们的上下文和目标，以及当前正在做的事情——如果理解不到位，我们应当更加详细地澄清和补充说明。
判断 Coding 工具是否理解了我们的上下文，我们可以采用多种方式：
- 查看 Coding 工具输出的中间信息
- 要求 Coding 工具在完成一个任务后输出报告，告诉我们它做了什么
- 要求 Coding 工具自我解释对于本次任务的理解
一旦我们确认它在正确的方向上做功，之后我们不必再描述和目标有关的事情，持续推进功能的完善，每次只需补充之前未曾提到的信息。
3. 三、安全审核
我自己使用 Trae 在 Coding 的过程中，Trae 使用一个数据库工具对数据库进行变更，变更之后整个数据库被清空。这个过程中它没有提醒我、要求我确认，事后无法恢复。这样的事情，在 Replit 这样的 Vibe Coding 工具上也出现过。
这涉及到的是一个安全审核的问题，即 AI 对项目做的重要操作，应当被用户监管，仅能执行授权的操作。为了实现这样的功能，AI Coding 的工具应当：
- 有一套沙箱机制，即 AI Coding 工具工作在一个与用户自己的系统隔离的环境中，AI 无法对该环境之外的系统造成直接破坏，除非用户自己授权
- 当 AI Coding 工具需要执行不在白名单中的操作时，需要用户授权
这样就确保了用户的知情权，相当程度地避免了灾难性的操作。
下面是一个 Codex CLI 申请授权高风险操作的案例：
图 4：Codex CLI 申请授权高风险操作案例——执行
git rm --cached移除文件跟踪前，提示需用户确认后才执行
上面的案例是 Coding 工具申请授权，还有一种则是用户主动授权：
图 5：用户主动授权案例——Codex CLI 列出授权选项（Yes / No / Always）由用户决策
对于不够聪明的模型来说，完全授权是极其危险的，务必做好数据的备份。我会在 AGENTS.md 文件中说明，执行某类高危操作之前，需要先对数据进行备份——顶级的 Coding 工具执行得非常好。
图 6：在 AGENTS.md 中说明高危操作前先备份数据的要求
4. 四、一次性与分阶段任务
有的人倡导将 PRD 写好一次性丢给 Coding 工具，有的人主张一步步完成。
这当然不是绝对的，取决于要解决问题的复杂程度。开发一个简单的文件迁移工具没有必要一步步来，但开发一个复杂的系统不可能一次性生成。
我来举 2 个例子。
我们在 序章 中已经提到过我的一个极客产品经理朋友，Geek PM，且称呼他为 GP。GP 开发的是将视频下载到 NAS 上，再将文件改名整理后迁移的脚本，这个脚本的功能不复杂。他的做法就是一次性写好需求，让 Coding 工具一口气开发完毕，然后再进行测试与修复问题，直到该脚本可以正常运作。
而我开发的是一个完整的 ToC 产品，有前后端，我需要一步一步实施——在这个过程中，设计方案、技术方案随时会变，假如强行一次性生成，模型会因为上下文超限而卡壳，并且后续再迭代或者修复问题可能会牵涉较大的范围。
正确的做法，就像专业的程序员那样，打下坚实的架构基础，再一步步添砖加瓦：我会在白纸上画出新界面的图，在图上标记不同区域的序号，拍照交给 Coding 工具，并用文字说明每个区域的作用、呈现内容、交互方式。但我会告诉 Coding 工具：在了解全貌之后，现在我们先专注于区域 1 的开发，另外 2 个区域留白等待未来实现。
当区域 1 开发和测试完毕后，我再开始完善区域 2，并且我会要求 Coding 工具在不同的文件中开发，而非同一个文件——我将代码刻意地组织在不同的文件中，与界面的格局一一对应。
5. 五、自解释能力
Coding 工具的自解释功能是很容易被遗忘的功能。
考虑如下一些场景：
- 朋友 GP 觉得一个简单的功能，为什么 Codex CLI 干了有半个小时？我回答他说：你何不直接问 Codex CLI？——让 Codex CLI 解释自己刚才工作内容的黑盒
- 我对 Codex CLI 的授权功能有点迷，因为它执行某个命令失败了，明显是没有权限，但并没有向我索要授权。于是我问：你命令执行失败了为什么不向我索要授权？——让 Codex CLI 自我反省，最终触发安全审核机制，而不是直接 Fail
- 我们可以让 Codex CLI 介绍自己的功能，甚至让它解释某个功能实现的技术原理，从而加强对它的学习
6. 六、过程与报告
营销类文章通常喜欢吹捧 AI 工具连续干活、自己去睡觉云云。
在我看来，"AI 作为辅助而用户才是掌控者"这一理念，说清楚用户应当有责任监督 AI 生成的过程信息——因为它反映了 AI 是否在正确的方向上做功。毕竟我们不想一觉醒来，发现 AI 南辕北辙，最后推倒重来，看着消费账单欲哭无泪。
关注 Coding 工具的过程信息：
- 判断他们是否陷入了死循环
- 判断他们是否在做无用功：Trae 总是尝试打开一个网页预览，验证自己的前端功能已开发完毕，但它又无法做到模拟鼠标点击预览页、切换页面，于是就卡在了那里
- 判断他们是否听懂了需求。你要求它修复某个问题，你预期问题应当是发生在某个模块或者文件中，那么 Coding 工具如果在检查这个模块或者文件中的代码，那么你可以放心地先去打一杯咖啡了
- 及时授权。安全审核做得好的 Coding 工具，会不停地向我们索要授权——那些想要睡一晚第二天看到成品的人够心大
当 Coding 工具完成当前的任务，我们应当要求它输出一份报告，汇报它刚才的工作内容，以防止我们万一错过了输出的过程——我们还可以通过汇报来回顾它刚才的做功是否正确。
7. 七、延缓代码腐化
代码腐化不可避免，但我们可以通过一些工作来尽可能减缓腐化的速度。这就必须要学习一些软件工程的知识，如果你现在还没有做好准备，可以不看这个部分的内容。
延缓代码腐化，第一要做的事情就是约束，第二则是小范围重构。
约束极为重要：
- 切换不同的模型干活，都遵循同一份约束，确保产出的代码风格不会差异过大。太大的差异性会导致变更范围扩大，代码难以阅读，误导后面新的模型
- 约束技术栈，避免同一类问题使用不同的技术来解决
- 约束代码目录结构，约定模块与文件的对应关系，约定代码文件、资源文件、脚本文件各自存放的位置，既方便阅读，也容易让所有模型理解
- 文件夹、文件、代码变量的命名，严格遵循规范，见名知义
- 写好注释，做好单元测试，必要的时候编写临时脚本测试 HTTP 接口（Codex CLI 经常这么干）
小范围重构，是针对遗留的技术债务而言，它们是极为有效的避免代码腐化的手段，尤其是产品核心代码，要尽力保持它的稳定，及时修复问题。
- 务必使用最强的模型，对于产品中那些核心的环节，阅读并给出优化的方案，在确认方案后实施
- 做好代码的备份，这通常来说是通过代码版本管理工具（如 Git）来实现
- 小范围重构不能等到出现大问题才去修复，而是发生在日常的 Coding 中，因为代码库越庞大，各个功能耦合性可能就越强，病入膏肓才优化的话，牵一发而动全身
8. 八、总结
AI Coding 并不是某个工具或某几条秘籍，而是一整套可迁移的思维方式。无论是网页、IDE 还是命令行，形式只是外壳，真正决定产出的仍然是我们对上下文的理解、对Agent 的配置，以及持续迭代的习惯。技术细节可以慢慢学，但"让 AI 成为可靠合作者"的意识必须从第一天建立。保持好奇、敢于实验、及时整理自己的 Agent Manifest，不仅能让模型输出更精准，也能让自己在飞速变化的 AI 浪潮中始终保持主动。