用大模型写代码大半年，有些坑踩过不止一次。下面这 4 个点，都是我在实际项目里验证过的，能少走不少弯路。

1. 开干前，先确认模型熟不熟你的框架

不同模型对各框架的训练数据覆盖差很多。gin 这种老牌高星框架，模型基本门儿清；hertz 这类新出的，受训练时间窗所限，模型明显生疏。联网能补一点，但"现查文档边写"的效率和稳定性，还是不如模型脑子里本就有。还有一类情况更棘手：模型是内网私有化部署的，根本没有联网能力，连"现查文档"这条路都断了。这时它能用的只有训练语料，遇到新框架会更局限——对策无非两种，要么提前把官方文档、示例代码整理好喂给它，要么直接选语料更充足的成熟框架。

我的习惯是，正式写之前先问一句：

你了解 xxxx 这个框架吗？请简要说明它的核心概念和典型用法。

看它回得怎么样，再决定下一步：

• 答得溜 → 直接上；
• 答得磕巴 → 先甩官方文档或示例代码再写；
• 一问三不知 → 换模型，或者干脆换更成熟的框架。

2. AGENTS.md 要当"规矩"写，别当"说明书"

AGENTS.md 是写给 Coding Agent 看的约束文档，别写成 README。两者根本不是一回事：

我一般立两条：

1. DRY：明令模型别写重复逻辑，优先复用现成的函数、模块。
2. 自动同步：项目一改功能，就让模型顺手把 AGENTS.md 也更新了，免得文档和代码对不上。

写进 AGENTS.md 大概长这样：

## 编码约束
- 遵循 DRY：禁止生成与既有代码重复的逻辑，优先复用现有函数/模块。
- 代码变更后，若影响了模块职责或目录结构，必须同步更新本文件对应章节。

3. 大需求拆阶段，别一次性甩给模型

需求改动面一大，模型一次给你生成的 spec 可能几十项任务。受上下文窗口和压缩机制所限，一把梭有两个毛病：后头的任务因为信息被压掉，容易跑偏；单次耗时太长，中途出错还不好定位。

我的做法是，把活儿切成阶段，每阶段十来个任务：

phase-1.md  # 任务 1~10：基础骨架与核心接口
phase-2.md  # 任务 11~20：业务逻辑与数据层
phase-3.md  # 任务 21~30：联调、测试与边界处理

一段一段推，模型注意力集中，落地也稳，还方便每阶段验收。

4. 用 ADR 记"为啥这么定"，别把中间草稿都撂仓库

用 superpowers 那套 skill 的话，每次头脑风暴都吐一堆 spec、plan。让仓库长期存这些草稿，价值不大。

更划算的是让模型出一份 ADR（架构决策记录），只盯"为什么这么定"：

# ADR-0001: 采用 gin 而非 hertz 作为 Web 框架

## 状态
已采纳

## 背景
项目需要快速搭建稳定的 HTTP 服务。

## 决策
选用 gin：社区成熟、模型训练语料充分，AI 辅助开发效率高。

## 后果
- 正向：开发速度快、踩坑少。
- 风险：gin 生态偏传统，后续如需极致性能再评估。

日后改方案，翻一眼就知道当初怎么想的。

上面几条都是真刀真枪项目里磨出来的，挑顺手的先试，别一股脑全上。