AI Coding 方法论与实战指南（2026 增强版）

开篇唠两句

我是折腾派程序员，一个专门把自己折腾明白再讲给你听的工程师。这篇文章，就是我在 2026 年初对 AI Coding 方法论的完整梳理。

最近在准备大厂面试，把这两年跟 AI Agent 打交道的心得从头到尾理了一遍。发现网上关于"AI Coding"的文章普遍有两个极端：要么只讲高大上的"Agent 工程化"概念，但没给出工业级的可复现工程实践；要么直接说"Vibe Coding"玩一玩就行，完全不提 45% 的 AI 生成代码包含安全漏洞这个致命事实。

这篇文章要做的，就是把 AI Coding 最核心的四块内容------"认知框架、工程脚手架、上下文管理、提示词结构"------串成一条能直接用在实战项目中的完整工业级链路。无论你是个人创业、团队协作还是生产系统，都能找到对应的方法论和可复现的操作清单。

版本说明：本文基于 2025--2026 年最新研究（DORA 2025 报告、Veracode GenAI 安全报告、Andrej Karpathy 工作流实录、多项同行评审研究）对原有方法论进行了系统性批判、修订与扩充，以提升可信度与实操价值。

前言：一个必要的认知校正

"Vibe Coding" 一词由 Andrej Karpathy 于 2025 年 2 月 在 X（原 Twitter）上首次提出，描述的是：你用自然语言与 AI 对话，AI 负责构建应用，你甚至不看生成的代码。这种方式对低风险、快速原型场景是合适的。

但到了 2026 年初，Karpathy 本人公开发文记录了更深刻的转变：他在约两个月内从"80% 手写代码 + 20% AI 辅助"切换到了"80% Agent 驱动 + 20% 人工编辑 "------他称之为"二十年来编码工作流最大的一次相变"。与此同时，业界开始使用更精确的术语：Agentic Engineering（Agent 工程化）。

Agentic Engineering 的本质是：以 AI 驱动的编码 Agent 作为力量倍增器，在你的主导下工作，由你保留对架构、代码质量和工程判断的完全责任。

学术研究（arXiv:2512.14012）对专业开发者的实地调研印证了这一点：专业开发者并不 Vibe Code------他们通过规划和监督对 Agent 进行精细管控，追求生产力提升的同时高度重视软件质量。

本文的目标：帮你从"让 AI 随便写代码"升级为"用工程化思维驾驭 AI Agent 系统性构建可维护软件"。

一、先看数据：AI Coding 的真实效益与代价

在展开方法论之前，理解真实的行业数据至关重要，因为它们揭示了一个你必须正视的矛盾：

1.1 效益端（确实显著）

90% 的技术从业者现在在工作中使用 AI（DORA 2025 Report，较 2024 年增长 14%）
80% 以上的受访者认为 AI 提升了个人生产力（DORA 2025）
59% 的受访者认为 AI 对代码质量有积极影响（DORA 2025）
使用 AI 的开发者每天处理 67.4% 更多 PR 上下文（Faros AI 2026 遥测数据）

1.2 代价端（常被忽视）

45% 的 AI 生成代码包含安全漏洞（Veracode《2025 GenAI 代码安全报告》，分析了 100+ LLM 的 80 个真实编码任务）
AI 生成代码引入的安全漏洞是人类编写代码的 2.74 倍（CodeRabbit 2025 年研究，分析 470 个真实开源 PR）
针对 534 个 AI 生成样本的测试中，25.1% 包含经 OWASP Top 10 验证的漏洞（AppSec Santa 2026）
每个 PR 对应的生产故障数上升了 242.7%（Faros AI 2026）
Agentic AI CVE 漏洞数量同比增长 255.4%（Trend Micro 2025）

1.3 "AI 生产力悖论"

这是 Faros AI 基于 10,000+ 开发者遥测数据总结的核心规律：

AI 编码助手显著提升个人产出（多完成 21% 的任务，多合并 98% 的 PR），但组织层面的交付指标纹丝不动------甚至恶化。

原因是：AI 在写代码阶段节省的时间，被重新分配到了代码审查、安全扫描和修复漏洞上。AI 是一个放大器------它放大团队的优势，也放大团队的问题。没有工程纪律支撑的 AI 采用，只会更快地积累技术债。

结论：方法论不是可选项，是保障 AI Coding 真正产生价值的前提。

二、核心认知框架

2.1 AI Agent 的正确心智模型

原有"强大但需要严格管理的实习生"比喻有一定价值，但不够精确。更准确的描述来自 Karpathy 本人记录的四大失败模式：

失败模式	具体表现	应对策略
静默假设	对不确定的问题自行猜测并继续执行，而不是主动提问	在所有提示词中明确要求：不确定时必须询问
过度工程	把 50 行能解决的问题写成 500 行的"框架"	在 Agent 配置中写入"最简可用解"原则
边界侵入	修改未被要求修改的代码文件	明确规定每次任务的文件边界
上下文丢失	在长会话中忘记早前的约束或已拒绝的方案	使用 token 预算和会话重置策略

这四个问题可以（也应该）被编码进 Agent 配置文件中，成为持久生效的行为约束------而不是每次都靠提示词重复强调。

2.2 Vibe Coding vs. Agentic Engineering 的适用边界

不要把两者对立，而要按场景选用：

维度	Vibe Coding	Agentic Engineering
适用场景	个人原型、概念验证、一次性脚本	生产系统、团队协作、需长期维护的项目
人工介入	极少或不介入	持续监督，人保留最终判断权
代码审查	通常跳过	强制执行
安全扫描	通常跳过	硬性门禁
技术债风险	高	可控

最佳实践（2026 年业界共识）：用 Vibe Coding 做原型和 MVP，在推向生产前引入工程化的代码审查、测试和安全扫描。

三、环境搭建（Pre-work）

3.1 工程脚手架

bash 复制代码

# Python 项目（推荐使用 uv）
uv init my-project
cd my-project

# 安装质量工具链
uv add --dev mypy ruff pytest pytest-cov

3.2 核心质量工具配置

toml 复制代码

# pyproject.toml
[tool.ruff]
line-length = 100
select = ["E", "F", "I", "N", "W", "UP"]

[tool.mypy]
strict = true
ignore_missing_imports = false

[tool.pytest.ini_options]
addopts = "--cov=src --cov-report=term-missing --cov-fail-under=80"

3.3 Agent 配置文件（CLAUDE.md）------ 2026 年最重要的新增实践

CLAUDE.md 是 Claude Code 在每次会话开始时自动读取的配置文件。等价物在其他工具中叫 .cursorrules（Cursor）、AGENTS.md 等。这是你与 Agent 之间的持久契约，将行为规范从"每次提示词重复强调"变成"一次写入，永久生效"。

创建项目级 CLAUDE.md 的标准结构：

markdown 复制代码

# 项目行为规范

## 核心原则

1. **不做静默假设**：遇到任何不确定之处，立即提问，不猜测
2. **最简可用解**：用最少的代码解决问题；不添加未被要求的功能或抽象
3. **遵守边界**：只修改被明确指定的文件，其他文件只读
4. **定义成功标准**：开始任何实现前，先用伪代码或测试用例描述预期结果

## 技术栈与约定

- Python 3.12+，类型注解强制要求
- 使用 ruff 格式化，mypy strict 模式检查
- 测试框架：pytest，覆盖率要求 ≥ 80%

## 项目结构

- src/：核心业务逻辑
- tests/：测试用例
- doc/：设计文档

## 禁止行为

- 不在代码中硬编码 API Key 或密码
- 不跳过异常处理
- 不在未经要求的情况下升级依赖版本

参考来源 ：Andrej Karpathy 2026 年 1 月公开发布的工作流转变记录中提及了这个文件；开发者 Forrest Chang 将其规范化为可复用的模板，该仓库数周内累计超过 22 万 GitHub Star，成为 AI 编码社区增长最快的仓库之一。

3.4 目录结构约定

bash 复制代码

project/
├── CLAUDE.md          # Agent 行为配置（自动读取）
├── doc/
│   ├── proposal.md    # 需求文档
│   ├── design.md      # 架构设计
│   ├── tasks/         # 模块任务清单
│   └── progress.md    # 全局进度追踪
├── src/
├── tests/
└── pyproject.toml

四、7 步核心工作流

步骤 1：问题定义与需求澄清（Proposal）

目标：将模糊想法转化为清晰、可执行、边界明确的需求文档。

提示词结构（四部分框架）

shell 复制代码

## 目标
[最终想要达成的结果，用"我想让用户能够..."句式描述]

## 输入（当前资源）
[已有的代码、数据、技术约束、不可更改的条件]

## 输出要求
[生成 doc/proposal.md，包含：功能列表、约束边界、非功能需求、风险]

## 步骤
1. 先列出所有你不确定的点，主动向我提问
2. 确认后再开始撰写文档
3. 禁止猜测任何不明确的需求

输出检查清单（proposal.md 应包含）：

核心用户故事（User Stories）
功能边界（哪些不在范围内）
技术约束（语言、框架、部署环境）
非功能需求（性能目标、并发量、延迟要求）
已知风险与前提假设
验收标准（可量化）

步骤 2：方案决策

让 AI 提出 2--3 个备选方案，每个方案覆盖：

核心思路
优势 / 劣势
技术风险
实现难度（人天估算）
长期可维护性

注意：方案决策是人的职责，不是 AI 的。AI 提供分析，你做决定，并将决定和理由记录进文档。

步骤 3：架构与设计（Design）

新建会话 （清空上下文），仅传入 proposal.md。

概要设计输出物

模块划分图（Mermaid 绘制）
核心数据流（输入 → 处理 → 输出）
接口定义（函数签名 / API 端点）
外部依赖清单

详细设计输出物（每个模块）

核心数据结构（Python dataclass / Pydantic Model）
关键算法描述
错误处理策略
状态管理方式

Mermaid 示例：

graph TD A[用户输入] --> B[输入校验层] B --> C{校验通过?} C -- 否 --> D[返回错误] C -- 是 --> E[核心处理层] E --> F[结果格式化] F --> G[输出]

步骤 4：任务拆分（Task Breakdown）

颗粒度原则 ：每个任务应该可以在不超过 2 小时内独立实现和测试。

任务文件模板（`doc/tasks/module_xxx.md`）

markdown 复制代码

# 模块：[模块名]

## 任务列表

- [ ] T1: 实现数据模型 (`src/models/xxx.py`)
  - 预计时间：30 min
  - 验收：mypy 通过，单元测试覆盖主要字段校验
- [ ] T2: 实现核心处理逻辑 (`src/services/xxx.py`)
  - 依赖：T1 完成
  - 预计时间：60 min
  - 验收：3 个典型场景通过，1 个异常场景通过
- [ ] T3: 集成测试
  - 依赖：T1, T2 完成
  - 预计时间：30 min

## 上下文边界

只允许修改以下文件：

- src/models/xxx.py
- src/services/xxx.py
- tests/test_xxx.py

## 相关文档

- 设计文档：doc/design.md#模块名章节

步骤 5：最小闭环迭代实现（Implementation）

5.1 MVP 优先原则

第一阶段只实现"主链路"：输入 → 核心处理 → 输出可以端到端跑通。哪怕是 hardcode 的中间步骤，也比追求完整性更有价值------因为它能让你尽早发现设计缺陷。

5.2 每步迭代的验证门禁

bash 复制代码

# 每次提交前必须全部通过
ruff check src/ tests/       # 代码规范
mypy src/                    # 类型检查
pytest tests/ -v             # 单元测试

5.3 多 Agent 协作模式（适用于复杂项目）

2026 年的工具生态已形成清晰的三层编排模型：

层级	模式	工具示例	适用场景
Tier 1	本地交互	Claude Code 单会话	单模块开发、问题排查
Tier 2	本地并行	Claude Code 子 Agent + tmux/worktree	3-10 个模块并行开发
Tier 3	云端异步	Claude Code Web、GitHub Copilot Agent	后台处理大批量任务

成本注意 ：并行运行 Agent 会线性消耗 token 配额。运行 5 个并行 Agent，日均花费可能达到 $50--65（Anthropic 工程实践数据）。先在 Tier 1 验证思路，再扩展到并行。

主 Agent + 子 Agent 模式（Claude Code）：

markdown 复制代码

# 主 Agent 提示词模板

你是项目监工 Agent。根据 doc/progress.md，当前待处理任务为：
[任务列表]

请为每个任务生成一个独立的子 Agent 指令文件（prompt_taskN.md），要求：

1. 每个文件只包含单一任务的完整上下文
2. 明确指定允许修改的文件范围
3. 指定验收标准（命令行可运行的测试）
4. 子 Agent 完成后更新 doc/progress.md 中对应的状态

关键原则：子 Agent 上下文越短越好，越专注越好。主 Agent 通过文档（而非对话历史）传递状态。

步骤 6：安全审查与健壮性测试

这是原方法论最严重的缺失。鉴于 AI 生成代码引入安全漏洞的概率高达 45%，安全审查必须作为独立的、强制的流程阶段。

6.1 AI 代码的高危漏洞模式

根据 Veracode 2025 报告和 AppSec Santa 2026 数据，AI 生成代码最常见的漏洞类型：

注入攻击（CWE-78/89/94） ：占所有已确认漏洞的 33.1%
- SQL 注入、命令注入、代码注入
- 检查每一个接受外部输入的数据库查询和系统调用
SSRF（CWE-918） ：服务端请求伪造
- 检查所有发起 HTTP 请求的代码段
硬编码凭据 ：AI 工具经常在示例代码中生成硬编码 API Key
- 全项目搜索：grep -r "api_key\|password\|secret\|token" src/
不安全的依赖：86% 的 AI 驱动环境使用包含高危漏洞的第三方包（Veracode 2026）

6.2 自动化安全扫描集成

bash 复制代码

# 安装安全工具
pip install bandit safety semgrep --break-system-packages

# Bandit：Python 安全静态分析
bandit -r src/ -ll

# Safety：依赖漏洞检查
safety check

# 检查敏感信息泄露（加入 pre-commit hook）
pip install detect-secrets
detect-secrets scan > .secrets.baseline

6.3 功能边界与健壮性测试

切换为"测试工程师"视角，系统覆盖：

python 复制代码

# 测试用例设计模板
class TestXxx:
    # 正常路径
    def test_happy_path(self): ...

    # 边界值
    def test_empty_input(self): ...
    def test_max_length_input(self): ...
    def test_special_characters(self): ...

    # 异常处理
    def test_invalid_type_raises(self): ...
    def test_network_timeout_handled(self): ...
    def test_database_unavailable(self): ...

    # 并发（如适用）
    def test_concurrent_requests(self): ...

6.4 MCP 服务器安全注意事项（2026 年新风险）

若你的 Agent 使用了 MCP（Model Context Protocol）服务器：

最小权限原则：Agent 的文件系统权限应显式限制在项目目录内
审查所有 MCP 服务器：不要使用未经审计的社区 MCP 插件
Prompt Injection 防御：如果 Agent 会读取外部内容（网页、文件），要防范内容中嵌入的恶意指令

步骤 7：验收与交付

7.1 正式验收检查清单

对照 doc/proposal.md 中每条验收标准逐一验证
所有自动化测试通过（pytest 全绿）
类型检查通过（mypy 无错误）
代码规范通过（ruff 无 error 级别问题）
安全扫描通过（bandit 无 High/Medium 问题）
依赖漏洞检查通过（safety check 无高危漏洞）

7.2 交付物清单

bash 复制代码

交付物/
├── 完整源码（含测试）
├── README.md           # 架构概述、安装方法、启动命令、使用示例
├── doc/
│   ├── proposal.md     # 需求文档
│   ├── design.md       # 架构设计
│   └── adr/            # Architecture Decision Records（关键决策记录）
├── SECURITY.md         # 已知安全注意事项
└── CHANGELOG.md        # 变更历史

五、上下文工程（Context Engineering）精要

上下文工程是 2026 年 AI Coding 最关键的隐性技能。AI Agent 的输出质量，在很大程度上取决于你给它提供了什么信息、以什么形式提供。

5.1 Token 预算管理

基于社区实践（Karpathy CLAUDE.md 社区 2026 年扩展版）的建议参数：

边界	推荐值	超出时的操作
单任务上下文	~4,000 tokens	拆分任务
单会话上下文	~30,000 tokens	总结 + 开新会话

实际信号：当你发现 Agent 开始重新建议你早已明确拒绝过的方案时，说明上下文已严重污染，必须重置。

5.2 信息传递原则

✅ 通过文档传递（持久、结构化、可版本控制）：

需求约束
架构决策
当前任务边界
验收标准

❌ 避免通过聊天记录传递（易丢失、易污染、难复现）：

关键的技术约束
禁止修改的模块
已确认的方案选型

5.3 新建会话的时机

下列情况必须新建会话：

切换到不同模块的开发任务
当前 Agent 开始重复之前已拒绝的建议
感觉 Agent 的输出质量在下降
步骤 3 → 步骤 4 的切换（设计完成，开始任务拆分）

新会话不是"失败"，而是保持 Agent 状态干净的主动管理手段。

5.4 仓库探索提示词（首次接触大型代码库时）

markdown 复制代码

分析这个代码仓库，给出：
1. 整体架构概述（核心模块及其职责）
2. 主要入口点（启动脚本、主函数、API 路由注册位置）
3. 数据流路径（请求如何从入口到达数据库或外部服务）
4. 关键配置文件位置
5. 现有测试的覆盖范围评估

完成后生成一份 doc/repo_map.md 作为后续任务的基础上下文。

六、Prompt 工程最佳实践

6.1 结构化四部分框架（复用模板）

markdown 复制代码

## 目标
[用"我想让系统能够..."句式，描述可量化的最终结果]

## 输入（当前资源）
- 现有代码：[文件路径]
- 设计文档：[doc/design.md#章节]
- 技术约束：[关键限制条件]

## 输出要求
- 文件：[具体文件路径]
- 格式：[Python 类 / REST API / 命令行工具]
- 验收：[可运行的命令 + 预期输出]

## 执行步骤
1. 先陈述你对任务的理解，列出所有假设
2. 如有任何不确定的地方，先提问，不猜测
3. 确认理解后，用伪代码描述实现思路
4. 经过我确认后，再开始写实际代码

6.2 常见提示词反模式（应避免）

反模式	问题	改进方向
"帮我实现这个功能"	无边界、无验收标准	明确文件范围和验收条件
"修一下这个 bug"	无复现步骤、无预期行为	提供最小复现案例和期望结果
"优化一下代码"	优化目标不明确	指定：速度/内存/可读性，以及优化幅度目标
"用更好的方式重写"	"更好"无法量化	说明当前问题是什么，改写后应解决什么

七、Bug 处理工作流

遇到 Bug 时，立刻停止当前路径，按以下流程处理：

markdown 复制代码

1. 重现
   └─ 写出能稳定复现 bug 的最小测试用例
   └─ 记录：预期行为 vs 实际行为 vs 复现步骤

2. 根因分析（开新会话，提供 bug 描述 + 最小复现）
   └─ 上下文污染？（Agent 已偏离原始任务）
   └─ 任务颗粒度过大？（一次改动太多）
   └─ 边界侵入？（Agent 修改了不该修改的代码）
   └─ 真正的逻辑 bug？

3. 方案对比（让 AI 提出 2-3 种修复方案）
   └─ 侵入范围最小的方案优先
   └─ 排除"大规模重构"类方案（除非根因确实是设计问题）

4. 修复 → 验证
   └─ 先跑专项测试用例
   └─ 再跑全量测试套件
   └─ mypy + ruff 全部通过

5. 记录（在对应任务文档中补充）
   └─ 根因描述
   └─ 修复方案及选择理由
   └─ 新增测试用例的说明

八、常见问题与解决方案

问题	根因	解决方案
AI 目标漂移	上下文过长，早期约束丢失	频繁引用需求/设计文档；设置 session token 上限
上下文混乱	单会话承载过多任务	每个模块开新会话，通过文档而非对话传递状态
代码变成屎山	跳过设计直接实现	严格执行步骤 3（架构设计）；每完成一个模块做一次小重构
生成质量低	提示词模糊，无验收标准	使用四部分结构化提示词；先让 AI 写测试
安全漏洞	AI 对安全实践不敏感	集成 bandit/safety/semgrep 作为 CI 必须通过的门禁
任务卡住	任务颗粒度过大	把当前任务再拆分为更小的子任务（< 2 小时粒度）
Agent 修改了不该改的文件	没有明确文件边界	在任务文档和 CLAUDE.md 中显式声明文件边界
测试覆盖率不足	先实现后测试，测试成为形式	先写测试（或先写伪代码测试），再写实现
重复建议已拒绝方案	上下文污染严重	立即开新会话，重新注入干净的任务上下文

九、工具选型参考（2026 年现状）

9.1 AI Coding 工具分类

类别	工具	特点
终端 Agent	Claude Code	深度代码库理解，支持子 Agent；适合复杂项目
IDE 插件	Cursor、Windsurf	交互友好，上手门槛低
成本优先	Cline + DeepSeek/OpenRouter	通过 API 路由控制成本
无代码/低代码	Lovable、Bolt	Vibe Coding 场景，快速原型

9.2 模型分层使用（多 Agent 场景的成本优化）

任务类型	推荐模型	原因
复杂架构推理、需求分析	Claude Opus（高端模型）	需要深度推理能力
日常编码任务（大多数场景）	Claude Sonnet	能力/成本平衡最优
简单格式化、注释、文档任务	Claude Haiku（轻量模型）	成本极低，响应快

9.3 代码质量工具栈

scss 复制代码

静态分析：ruff（替代 flake8 + isort + black）
类型检查：mypy（strict 模式）
安全扫描：bandit + safety + semgrep
测试框架：pytest + pytest-cov
依赖管理：uv（替代 poetry，速度快 10-100x）
版本控制钩子：pre-commit

十、总结与行动建议

核心价值

这套方法论将"让 AI 随便写代码"升级为"工程化驾驭 AI Agent 构建可维护软件"。

它解决的本质问题 ：AI 是生产力放大器，但放大的是团队的所有行为------包括工程纪律不足带来的技术债。方法论就是在放大好的工程实践，同时抑制 AI 加速积累问题的倾向。

三个立刻可以执行的行动

创建 CLAUDE.md：为你现有的项目写一个 30 行左右的 Agent 行为配置文件，把你对 AI 的隐性期望变成显性约定
集成安全扫描 ：在项目 CI 中加入 bandit 和 safety，让安全检查成为自动门禁而非手动步骤
文档驱动一个功能：选一个接下来要实现的功能，完整走一遍"Proposal → Design → Tasks"三步，再开始写代码，感受有无文档锚点的差异

适用范围

个人项目、团队协作、生产系统、内部工具。复杂程度越高，方法论的价值越显著；简单脚本可简化执行（跳过步骤 2--4）。

附录：关键数据来源

数据	来源	时间
90% 开发者使用 AI	DORA State of AI-Assisted Software Development 报告	2025
45% AI 代码含安全漏洞	Veracode GenAI Code Security Report	2025
AI 代码漏洞率是人类 2.74x	CodeRabbit State of AI vs Human Code Generation	2025 Q4
每 PR 生产故障增长 242.7%	Faros AI 遥测数据（10,000+ 开发者）	2026
Agentic AI CVE 增长 255.4%	Trend Micro TrendAI 报告	2025
Karpathy 工作流转变记录	Andrej Karpathy X 帖子	2026 年 1 月
专业开发者不 Vibe Code	arXiv:2512.14012，45 分钟实地观察 + 访谈研究	2025 Q4

结尾：搬好小板凳，我们直接开折腾！

如果你已经读到这里，说明你已经理解了 2026 年 AI Coding 的核心悖论：生产力提升的背后隐藏的是风险放大。

这套方法论的价值就在于：把 AI 当作力量倍增器来用，而不是让它成为债务倍增器。

立刻可以开始的三个行动

为你的项目创建 CLAUDE.md（或 .instructions.md）
- 把对 AI 的隐性期望变成显性约定
- 让每次对话都从同一个基线开始
- 30-50 行就足够了
集成一个安全扫描工具到 CI/CD
- 选 bandit + safety 之一（Python）或对应语言的工具
- 让安全检查成为自动门禁，而不是手动步骤
- 这一个改变，能把 45% 的漏洞概率降到个位数
用文档驱动下一个功能的开发
- 选一个接下来要实现的功能
- 完整走一遍"需求 → 设计 → 任务分解"三步
- 再开始让 AI 写代码
- 你会真切感受到有无文档锚点的天壤之别

有问题，欢迎交流

如果这篇文章对你有帮助，点个赞是对我最大的支持 ❤️

有任何疑问、建议，或者你的实践中遇到了本文没涉及的问题，欢迎在评论区交流。大家一起在讨论中碰撞出新的想法😂。

折腾不止，进步不停 🚀

AI Coding 方法论与实战指南（2026 增强版）

开篇唠两句

前言：一个必要的认知校正

一、先看数据：AI Coding 的真实效益与代价

1.1 效益端（确实显著）

1.2 代价端（常被忽视）

1.3 "AI 生产力悖论"

二、核心认知框架

2.1 AI Agent 的正确心智模型

2.2 Vibe Coding vs. Agentic Engineering 的适用边界

三、环境搭建（Pre-work）

3.1 工程脚手架

3.2 核心质量工具配置

3.3 Agent 配置文件（CLAUDE.md）------ 2026 年最重要的新增实践

3.4 目录结构约定

四、7 步核心工作流

步骤 1：问题定义与需求澄清（Proposal）

提示词结构（四部分框架）

步骤 2：方案决策

步骤 3：架构与设计（Design）

概要设计输出物

详细设计输出物（每个模块）

步骤 4：任务拆分（Task Breakdown）

任务文件模板（doc/tasks/module_xxx.md）

步骤 5：最小闭环迭代实现（Implementation）

5.1 MVP 优先原则

5.2 每步迭代的验证门禁

5.3 多 Agent 协作模式（适用于复杂项目）

步骤 6：安全审查与健壮性测试

6.1 AI 代码的高危漏洞模式

6.2 自动化安全扫描集成

6.3 功能边界与健壮性测试

6.4 MCP 服务器安全注意事项（2026 年新风险）

步骤 7：验收与交付

7.1 正式验收检查清单

7.2 交付物清单

五、上下文工程（Context Engineering）精要

5.1 Token 预算管理

5.2 信息传递原则

5.3 新建会话的时机

5.4 仓库探索提示词（首次接触大型代码库时）

六、Prompt 工程最佳实践

6.1 结构化四部分框架（复用模板）

6.2 常见提示词反模式（应避免）

七、Bug 处理工作流

八、常见问题与解决方案

九、工具选型参考（2026 年现状）

9.1 AI Coding 工具分类

9.2 模型分层使用（多 Agent 场景的成本优化）

9.3 代码质量工具栈

十、总结与行动建议

核心价值

三个立刻可以执行的行动

适用范围

附录：关键数据来源

结尾：搬好小板凳，我们直接开折腾！

立刻可以开始的三个行动

有问题，欢迎交流

任务文件模板（`doc/tasks/module_xxx.md`）