怎么更好地应用AI编程¶

AI 编程高效协作 10 条实战准则¶

准则 ① 先调研再动手¶

别急着让 AI 写代码。第一句话永远是：先帮我调研全网竞品，生成一份傻子都能看懂的报告。磨刀不误砍柴工，方向错了，写得再快也是废代码。

准则 ② 吃透需求，方案过审才开发¶

让 AI 先完整分析你的资料，确认理解了再动手。先出方案，用 Mermaid 图画出来，你确认了才开始写。AI 最大的问题不是写得慢，是写得快但方向跑偏。

准则 ③ 不确定就问，绝不瞎猜¶

告诉 AI：你有任何不确定的地方，必须提问找我确认，不要自己瞎猜。一个 5 秒钟的确认，省得你 5 小时的 debug。

准则 ④ 查最新文档，别用过时写法¶

AI 的训练数据有截止日期。让它用联网搜索获取最新技术文档，别用过时的写法。AI 给的 API 调用方式可能是废弃版本，跑起来全是报错。

准则 ⑤ 简单优先，只加不改¶

先用最简单直接的方式实现核心功能，避免过度设计。一定不要影响现有功能，只新增代码，遵循开闭原则。能跑通的烂代码 > 跑不通的好架构。

准则 ⑥ 把我当新手，保姆级引导¶

第一次做某个功能？告诉 AI：把我当傻子，给我充分的操作引导和步骤说明。别装懂，AI 不会笑话你，但上线后的 bug 会。

准则 ⑦ 前端要独特，别千篇一律¶

禁止蓝紫渐变！禁止模板感！让 AI 做出让人眼前一亮的页面，不是又一个 SaaS 后台。用户第一眼看的是界面，不是你的代码架构。

准则 ⑧ 多需求并行，规划优先级¶

同时给了多个需求？让 AI 合理规划优先级和依赖关系，能并行的并行，用最快速度完成，注意代码别冲突。

准则 ⑨ 自测自修，跑通再交付¶

让 AI 自主写测试用例、执行验证、出了问题自己修复。先测通了再找你验收。你验收的应该是成品，不是半成品。

准则 ⑩ 文档同步，Git 规范，封装复用¶

需求分析、方案设计沉淀为 Markdown，每次改完代码同步更新文档。提交 Git 写清楚 commit message。好的能力封装成 Skill 复用。今天偷的懒，明天都是技术债。

十条准则的核心本质¶

10 条的本质就一句话：给 AI 搭好脚手架。 先想再做、遇疑则问、测通再交、沉淀复用。

这在行业里有个专业叫法——Harness Engineering（脚手架工程）。不是 AI 不行，是你没给它搭好框架。

上下文管理十大技巧¶

大多数模型的上下文窗口虽高达 100 万 Token，但在达到约 40% 时，模型的注意力就会因被稀释而导致能力下降。Anthropic 官方指出：上下文越长，模型表现越差。Claude 的注意力会被越来越多的 Token 稀释，旧方案错误的假设与无关日志会开始干扰当前任务。

核心原则： 真正的上下文管理不是等它满了再说，而是从一开始就控制它看什么、丢什么。

技巧 1：用 /context 命令查看当前占用¶

通过 /context 命令观察上下文的实际使用情况，而不是凭感觉判断模型是否变笨。

技巧 2：提示词不要太短（反直觉）¶

明确告诉 AI 目标是什么、不要动哪里、重点看哪个文件，可以减少 AI 自行探索时摄入无用信息，让上下文更干净。

技巧 3：多主动用 /compact 命令¶

探索完成、方案已定、准备正式改代码时，使用 /compact 命令将上下文从"聊天记录"压缩为"工作交接"，保留架构判断、用户明确要求、已验证命令，丢弃无关试错过程。

技巧 4：新任务用 /clear 指令¶

完全无关的新任务应使用 /clear 命令新开会话，而非继续在旧会话中讨论。

技巧 5：错误路线用 /rewind 指令¶

当方案走不通时，回到错误发生之前的状态，丢弃失败尝试，再补充新约束，避免失败过程残留在上下文中。

技巧 6：旁支问题不要污染主线¶

临时想查询的旁支问题不要在主会话中直接问，而应使用 /btw 指令或专门开新会话隔离。

技巧 7：规划、执行、验收不要长期混在一个上下文里¶

复杂任务应先规划（影响文件、风险边界、验证方法），确认后再执行，执行完再验收。每个阶段结束都要评估是否需要 /compact 或 /clear。

技巧 8：大项目提任务时一定要给文件路径¶

明确指定文件路径，减少 AI 在全仓库中猜测和探索的消耗。

技巧 9：能隔离的噪音一定要隔离¶

会产生大量中间输出的任务（如全仓库搜索、日志分析、测试排查）应由 Sub-agent 处理，主会话只拿结论，不吃过程。

技巧 10：用 RTK 给输出截流¶

RTK（RutuKiller）在 Claude Code 的 Bash 工具和真实终端之间加一层代理，将工具执行噪音、重复日志、进度条等无用输出压缩，只将失败点和关键摘要送回上下文。一次 npm test 可能产生数百行日志，RTK 可减少约 89% 的命令噪音 Token 消耗。

附录：Agent 上下文管理——信息取舍与工程实践¶

延伸话题： Agent 不只是调 API。当对话轮次增加（如 50 轮），上下文 Token 超过模型窗口时，核心挑战是信息的取舍。

上下文窗口的固定开销¶

50 轮交互后易突破窗口限制，导致三大痛点：API 成本高、首 Token 延迟慢、Lost in the Middle（中间信息丢失）。

历史消息四分类¶

信息价值打分机制¶

核心思路是对每条消息打分，按分数决定处理方式：

打分规则： - 用户指令 → 0.4 分 - 包含关键决策 → 0.3 分 - 任务状态变更 → 0.2 分 - 时间衰减 → 0.1 分

处理逻辑（上下文 Token 超阈值时触发）： - 高分（>0.6）：保留原文 - 中分（0.3-0.6）：生成摘要 - 低分（<0.3）：激进压缩或丢弃

摘要时机优化： 触发阈值设为窗口的 80%，预留 20% Token 用于摘要本身。100 轮对话下，不做摘要累计约 500 万 Tokens，做摘要约 305 万 Tokens（含摘要调用），节省约 40%。

Prompt 优化验证与错误处理¶

Agent 的四个核心组件¶

Agent 有四个组件协同工作： - Model（判断器）：决定下一步干什么 - Loop（心跳）：让"判断→行动→观察"循环持续运转 - Tool（受控能力）：将模型意图连接到真实世界 - State（现场账本）：保证下一轮模型不是从零开始

优化 Prompt 不是在调一个人的台词，而是在调四个组件配合的方式。

Prompt 优化的三个验证维度¶

维度一：账本验证¶

系统日志中必须有三样东西： - Tool Call 记录：模型声称调用了工具不算，系统记录才算 - 退出码：没有后续测试命令的退出码，不能说明系统验证过 - 来源标注：Agent 在冲突信息中做判断时，来源信息决定可信度

维度二：错误分类¶

在推理链路中，错误分四类（详见 7.3 节），Prompt 优化有效与否就看这四类错误是否减少。

维度三：链路推进¶

判断 Prompt 优化是否有效，看三个指标： 1. 循环是否持续有效：任务有没有往前跑，而不是原地打转 2. 每一步是否保持状态连续性：Context 不中断，账本不断线 3. 控制系统是否有效：Agent 有没有跑飞到预期之外

四类常见错误及处理¶

链路推进的核心指标¶

一个只会回答问题的系统叫问答系统，一个能主动推进任务的系统才叫 Agent。判断优化效果的核心指标：

1. 完成率：相同测试集下，任务完成率是否提升
2. Token 消耗：完成任务所需轮次和 Token 是否减少
3. 直线性：是否在更少的轮次内完成，而非原地打转
4. 泛化能力：在正常 Case、边界 Case、失败 Case 上的表现是否稳定

进阶视角： Prompt 优化本质上是优化多智能体协作系统。可引入 RL 视角，使用奖励函数 R = R_relevant + λ × C_search_cost 来量化效果。

实践规则与技巧¶

提示词工程： 明确任务类型（代码生成、分析、优化），设置输出格式要求，提供示例参考。

结果校验： 验证代码正确性，检查逻辑完整性，评估性能优化效果。

Agentic Engineering：从 Vibe Coding 到 TDD 驱动¶

延伸阅读： Simon Willison（Django 创始人）提出的 Agentic Engineering 方法论，强调结构化、测试驱动的 AI 编程模式，区别于仅凭感觉的 Vibe Coding。

Vibe Coding vs Agentic Engineering¶

为什么 TDD 成为必须¶

先写测试的本质是明确"我要什么"，即通过测试用例定义功能的验收标准。Red/Green TDD 三步流程：

1. 红灯（Red）：先编写测试，预期失败
2. 绿灯（Green）：编写代码使测试通过
3. 重构（Refactor）：优化代码

First Run the Tests 三大好处¶

1. 让 AI 明确知道需要通过测试，促使其自动考虑测试兼容性
2. 测试数量能帮助 AI 判断项目规模，调整生成策略
3. 引导 AI 主动生成测试用例，形成"测试→代码"闭环

AI 编程时代的核心竞争力¶

AI 能在几分钟内生成数千行代码（如 1 人 + AI 一周重写 Next.js 框架，成本 1100 美元），代码产量不再是瓶颈，质量保障成为关键。此时"定义什么是对"的能力（即编写好的测试、明确验收标准）成为稀缺资源，Red/Green TDD 正是这一能力的核心实践。

Vibe Coding 一线实践者的经验与反思¶

实践情况： 尝试了多款国内外 AI 工具，以兴趣为导向手搓了 10 余个小产品，但无一款真正上线并形成闭环链路。

核心反思： 过程中未提升对软件工作系统的认知，大量时间消耗在与 AI 的自然语言对话和修 bug 上，产出的产品难以达到可上线并长期维护的标准，仅停留在"搓小玩具自我感动"的层面，认为单纯的 Vibe Coding 价值有限。

调整方向： - 停止盲目"瞎搓"，聚焦能落地、有实际应用价值的创意 - 明确自身目标，以"专业 AI 产品经理"或"全栈工程师"为标准，学习与 AI 协同并实现职场落地

Vibe Coding 的真正价值来源： - 拒绝跟风和自我感动，要么提升自身逻辑思维、产品认知，要么做出能落地解决问题的产品 - 以产品思维和工程逻辑拆解需求、梳理流程，而非盲目堆需求、瞎改 bug - 掌握与 AI 沟通、工具使用及 bug 调试的技巧 - 不被工具绑架，明确目标后快速执行，工具的好坏需亲身实践验证

评论