AI Coding 并非简单的'让 AI 写代码'，而是一种使用大型语言模型（LLM）为核心驱动力的新型软件编程方式。要求开发者不仅要理解编程语言，更要掌握模型边界感知、上下文工程、认知负载管理等新兴技能。
随着 Claude、GPT-4、Kimi 等模型的能力跃升，我们正从'AI 辅助编码'（Copilot 模式）变成'AI 主导架构，开发人员主导决策'的代理编程（Agentic Coding）。这一转变要求建立全新的工作流、质量控制体系和知识管理方法。
第一部分：核心概念、认知框架——基础概念
1.1 模型边界感知
AI Coding 的首要原则是清醒认知模型的能力边界。如同蒸米饭加水比例般凭感觉，而大模型则是基于概率预测，存在以下限制：
能力边界维度：
- 上下文窗口限制：当前主流模型支持 128K-200K tokens，但有效利用长度通常只有 8K-32K（随长度增加，召回率下降），通俗点就是前面很聪明，后面越来越笨，回答问题天南地北。
- 知识截止时间：模型对最新框架、API 变更存在盲区。
- 推理深度：复杂算法推导、多步骤逻辑链容易在中间环节出错。
- 幻觉概率：在陌生领域（如特定企业内部框架）容易生成看似合理但实际错误的代码。
任务拆解策略： 将复杂需求拆解为模型可稳定处理的单元：
❌ 错误：'给我写一个电商系统'
✅ 正确：拆解为 [用户认证模块] → [商品数据模型] → [购物车逻辑] → [支付接口对接]
每个子任务应满足：
- 单一职责：一个对话只解决一个具体技术问题。
- 输入完备：提供必要的接口定义、数据示例、约束条件。
- 输出可验证：结果可通过测试用例或类型检查验证。
1.2 上下文工程
比提示词（Prompt）更重要的是上下文（Context）的构建。这是 AI Coding 中最容易被忽视的专业技能。
上下文金字塔：
- 项目级上下文：架构图、技术栈、编码规范、目录结构。
- 任务级上下文：相关代码文件、依赖接口、业务逻辑背景。
- 会话级上下文：当前对话历史、已做出的决策、待解决问题。
最佳方法：
- RAG（检索增强生成）：使用向量数据库存储项目文档，动态检索相关片段注入提示。
- 文件引用规范：使用 XML 标签或特定格式（如
<file path="src/utils.js">）明确标识引用内容。 - 差异最小化：只提供变更相关的上下文，避免无关代码干扰模型注意力。
1.3 提示词工程
从'技巧'到'协议'的转变：
结构化提示模板（SPF）：
角色：你是一位资深后端工程师，专精分布式系统。
任务：重构以下 Python 函数，使其支持异步并发处理。
上下文：当前使用同步阻塞 I/O，目标 QPS：10,000，依赖库：asyncio, aiohttp。
输入代码：[代码块]
约束条件：保持现有 API 接口不变，添加类型注解，错误处理必须兼容现有日志格式。
输出要求：1. 重构后的完整代码；2. 关键变更点说明；3. 性能测试建议。
关键原则：
- 角色设定：明确期望的知识领域和回答风格。
- 约束条件：提前声明技术限制，减少无效尝试。
- 输出格式：结构化要求便于后续自动化处理。
第二部分：AI Coding 工作流与方法论
2.1 需求澄清与信息核对
AI Coding 的第一定律：输入的模糊性会直接导致输出的错误率指数级上升。
信息核对清单：
- [是/否] 业务术语是否有特定含义？（如'用户'是否包含匿名访客）
- [是/否] 技术约束是否明确？（浏览器兼容性、Python 版本、依赖限制）
- [是/否] 边界条件是否定义？（空值处理、并发限制、数据范围）
- [是/否] 验收标准是否量化？（性能指标、测试覆盖率）
有效方法：'反向复述'：要求 AI 用自己的语言重述需求，确认理解一致后再开始编码。
2.2 调试与错误处理协议
当 AI 生成代码出现错误时，遵循结构化报错流程：
错误报告模板：
问题描述：[一句话概括现象，如：运行时抛出 NullPointerException]
环境信息：语言/框架版本：... | 操作系统：... | 相关依赖版本：...
错误日志：[完整堆栈跟踪，使用 <error> 标签包裹]
已尝试方案：1. [方案 A] → 结果：... | 2. [方案 B] → 结果：...
期望行为：[描述正确的行为应该是怎样的]
相关代码：[最小可复现代码片段]
务必及时止损： 如果同一问题经过 3 轮迭代仍未解决：
- 开新对话窗口：重置上下文，避免错误累积。
- 降低复杂度：将问题拆分为更小的验证单元。
- 切换策略：从'AI 自动修复'转为'AI 提供方案，人工实施'。
2.3 版本控制、代码审查
AI 生成代码的版本管理特殊性：
- 生成元数据标记：在提交信息中标注使用的模型、提示词版本、温度参数。
- 隔离实验分支：AI 重构代码必须在独立分支进行，通过 PR 审查合并。
- 快照对比：使用工具（如 aider、cline）对比 AI 修改前后的差异。
审查清单：
- [是/否] 是否引入未声明的依赖？
- [是/否] 错误处理是否完备？
- [是/否] 是否存在潜在的安全漏洞（SQL 注入、XSS）？
- [是/否] 性能特征是否可接受？
第三部分：工程化与系统化
3.1 上下文窗口管理策略
长上下文的陷阱： 虽然模型支持 128K+ tokens，但**'支持'不等于'有效'**。当上下文超过 32K 时，模型对早期信息的召回率显著下降。
管理策略：
- 对话分片：每个对话窗口专注一个功能点，完成后将结论沉淀到 Wiki 或文档，新任务基于沉淀文档开启新对话。
- 记忆管理：使用外部记忆系统（如 Mem0、Zep）持久化项目知识，关键决策点（技术选型、架构设计）必须人工确认后存入记忆，定期整理记忆空间，删除过时信息。
- 增量更新：只传递变更差异（diff），而非完整文件，使用
git diff格式让模型理解修改范围。
3.2 MCP、工作流封装
MCP 架构是 AI Coding 的工程化核心，它将常用能力封装为标准接口：
| 类别 | 功能 | 示例 |
|---|---|---|
| 文件系统 | 读写代码、搜索文件、目录遍历 | read_file, search_code |
| 终端执行 | 运行命令、执行脚本、构建项目 | execute_command, run_tests |
| 网络请求 | API 调试、文档检索、依赖查询 | http_request, fetch_docs |
| 数据库 | Schema 查询、数据验证、迁移生成 | query_db, migrate |
| 版本控制 | Git 操作、差异查看、提交管理 | git_diff, commit |
工作流封装示例：
workflow: "安全重构"
steps:
- 分析：使用 AST 解析理解代码结构
- 规划：AI 生成重构方案（不修改代码）
- 验证：运行现有测试套件，确保基线通过
- 实施：按方案执行修改，每步后运行测试
- 回滚：如测试失败，自动回滚到上一步
- 审查：生成 diff 报告供人工确认
3.3 项目 Wiki 与知识管理
AI 友好型 Wiki 结构：
text
wiki/
├── 1.开始/
│ ├── 快速开始.md # 5 分钟运行 Hello World
│ ├── 环境搭建.md # 依赖安装、IDE 配置
│ └── 架构概览.md # 一张图看懂系统
├── 2.指南/
│ ├── 添加新功能.md # 端到端开发流程
│ ├── 调试技巧.md # 常见问题排查
│ └── 性能优化.md # 基准测试与调优
├── 3.参考/
│ ├── API 文档/ # 自动生成
│ ├── 配置手册.md # 环境变量、参数说明
│ └── 错误码表.md # 对照表与解决方案
└── 4.开发/
├── 贡献指南.md # 代码规范、提交格式
├── 架构决策记录 (ADR)/ # 关键设计决策
└── 路线图.md # 未来规划
AI 可读性优化：
- 使用机器可读格式（Markdown、YAML、JSON）。
- 显式优于隐式：明确写出默认值、边界条件、异常行为。
- 示例驱动：每个概念配有一个可运行的最小示例。
总结
4.1 误区
准备不完善，目标功能模糊，过早追求完美，对 AI 期望过高。
4.2 感想
目前已经有很多公司决定不再按照技术栈分技术岗位，统一为 Agent 工程师，工作安排上是根据产品、项目任务安排。
对于不懂的技术栈，最重要是要有一个基本的概念，配合 AI Coding 完成需求开发。对于门外汉来说，什么也不会的话，建议还是重 0 开始学习，之前是 0 到 1，现在可以 0 到 0.8 的学习，就可以做一些开发，然后在实际业务中学习。
