公司产品级应用的AI开发正确打开方式

Post Views: 91

我试过不少 AI 开发组合，包括 Codex 原生加 GPT 模型、Codex 加 DeepSeek、Codex 加 Agnes、Claude 加不同模型，以及 VS Code 里的 Copilot 加不同模型。

在真实公司项目里持续使用后，我目前的个人选择是：大部分模块开发、跨文件修改和长期任务优先用 Codex 加 DeepSeek；大模块完成后的修修补补、小型维护任务，交给 Codex 加 Agnes；遇到复杂架构设计、疑难问题、高风险改动时，再让 GPT 或 Claude 这类推理能力更强的模型参与方案评审和交叉检查。

这只是个人实践后的工具路线，不是对所有模型的绝对排名。模型、版本和工具链变化很快，同一种组合在不同项目里的表现也可能不同。

“工欲善其事，必先利其器”只说明了工具的重要性。真正决定产品级开发结果的，还是：需求是否完整，架构边界是否清楚，任务是否被拆小，结果是否经过验证，以及错误有没有被沉淀成项目规则。

最后我们的目标：尽可能节省Token、少返工、还能高效完成可扩展的产品级应用。

一、先看一个核心公式

有效产出 = 正确上下文 × 模型能力 × 工程约束 × 验证闭环 ÷ 返工次数

AI 开发的总成本也不能只按单次请求计算：

总成本 ≈ 单轮上下文 × 交互轮数 + 输出量 + 返工成本 + 人工排错成本

所以，“一次发很少的 Token”不等于“总成本低”。如果少给了上下文，导致模型连续几轮猜错，最后的总消耗会更高。

真正有效的做法是：

用恰当上下文让模型第一次就理解任务。
用项目规则限制模型不要自由发挥。
用架构和接口先冻结大方向。
用测试、编译、审查和运行结果验证。
把重复出现的问题写成规则或自动化检查。

二、工具选择：不要只用最强模型，要做模型路由

我的基本分工如下。

使用场景	首选工具组合	主要作用	注意事项
大模块开发	Codex 加 DeepSeek	跨文件修改、持续执行、批量重构	先给设计和边界，不要直接让它自由设计
小修小补	Codex 加 Agnes	小范围界面调整、小问题修复、局部完善	不适合承接高风险架构改造
复杂架构与疑难问题（架构级调整、主题和UI批量级优化）	Codex 加 GPT	方案对比、根因分析、复杂状态设计
前端视觉和交互	支持图片理解的多模态模型	看界面、比设计稿、定位布局问题	适当缩放容器（APP，浏览器等），图片要裁剪、并标注，避免整屏低价值输入
代码补全	VS Code Copilot	帮忙阅读、补充注释、生成某个功能的序列图脚本	已经不让它去编写代码了，偶尔跑一次agent，上下文会有缺失，不如我在codex中准确，全面。

1. 第一原则：按任务风险路由

高风险任务使用高能力模型：

系统架构。
数据模型。
权限模型。
并发和事务。
安全逻辑。
复杂状态机。
难以复现的生产问题。
大规模重构。

低风险任务使用成本更低的模型：

文案调整。
样式微调。
小型组件补充。
简单字段增加。
已有模式的重复实现。
小范围测试补充。

2. 第二原则：在一个任务边界内尽量不频繁换模型

频繁切换模型会带来三个问题：

上下文丢失。
输出风格变化。
同一个问题被不同模型重复解释。

更好的方式是：

一个明确任务
-> 一个主模型负责
-> 一个不同模型负责审查
-> 将最终结论写回项目文档或代码

3. 第三原则：让模型之间通过文档交接，而不是通过聊天记忆交接

架构模型输出：

docs/architecture/module-design.md
docs/adr/ADR-001-data-permission.md
docs/api/openapi.yaml

开发模型读取这些文件后再实现。

这样即使更换模型、重建会话或上下文被压缩，项目的关键事实也没有丢失。

三、如何真正减少 Token 使用量

1. 不要整仓库塞给模型

优先给路径，让 Agent 自己读取相关文件：

先阅读：
- src/modules/order/
- src/modules/inventory/
- docs/design/order-flow.md
- docs/api/openapi.yaml

只在完成阅读后修改代码。

对于不具备文件读取能力的工具，只附上相关文件，不要复制整个项目。

2. 上下文只保留完成任务必需的信息

一个高质量上下文包通常包含：

目标：
业务背景：
已有实现：
相关文件：
数据结构和接口：
约束：
不修改范围：
验收标准：
验证命令：

不相关模块、旧日志、全量截图和已经废弃的方案，不应反复带入新会话。

3. 控制输出形式

下面的提示词通常能明显减少无效输出：

直接执行任务，不要复述背景，不要重复现有代码。
输出只包含：
1. 实际修改文件
2. 关键变更
3. 验证命令和结果
4. 剩余风险
信息足够时直接执行，不要反复确认。

模型输出越短，并不代表质量越高，但可以减少以下无效内容：

重复解释需求。
再贴一遍大段原代码。
输出无关示例。
每轮都重写完整方案。
给出已经明确排除的备选方案。

4. 把长任务切开

推荐按阶段拆：

阶段 1：读取资料，输出事实和疑问
阶段 2：输出架构和边界，不写代码
阶段 3：冻结接口和数据模型
阶段 4：按垂直切片实现
阶段 5：运行测试和交叉审查
阶段 6：更新文档和规则

每个阶段形成明确产物后，再进入下一阶段。

5. 在正确的时候新开对话

建议新开对话的情况：

一个功能已经完成并验证。
任务从 ERP 模块切换到嵌入式模块。
从需求讨论切换到故障排查。
上下文里已经有大量无关历史。
模型开始反复引用已经废弃的方案。

不建议新开对话的情况：

还需要连续修改同一组文件。
当前任务中的关键决策尚未写入文档。
正在根据测试结果做连续修复。

6. 利用稳定的项目前缀

如果模型或平台支持提示词缓存，应把稳定内容放在固定文件中，例如：

AGENTS.md
docs/architecture/
docs/coding-standards/
docs/api/openapi.yaml

不要把稳定规则散落在每次对话的新提示词里。

四、图片交互会增加 Token 吗

会增加单轮输入的 Token，但是否增加“完成同一个任务的总成本”，要看图片解决了什么问题。

多模态模型会把图片转换成视觉 Token 或图像切片。具体转换方式取决于模型供应商、图片尺寸、分辨率和内部切片策略，不同平台的公式不一样，不能写死成一个数字。

可以确定的规律是：

图片通常会占用额外的视觉 Token。
图片越大、分辨率越高，通常消耗越多。
图片留在对话上下文里时，会持续占用上下文，影响后续轮次。
截图里如果包含大段代码和日志，通常不如直接提供文本高效。
一张裁剪并标注清楚的 UI 截图，可能比多轮文字描述更省总成本。
图片避免了误解和返工，单轮贵一点也可能是值得的。
提交图片的时候可以适当加注箭头指向，然后提示词里说明的时候会更方便描述。

场景	建议
UI 布局、间距、遮挡问题	使用裁剪后的截图，并标注区域
设计稿还原	同时给设计稿、当前页面和目标尺寸
系统架构	优先使用 Mermaid 或结构化文本，不要只给模糊图片
代码问题	直接给文件、函数、错误信息和相关上下文
日志问题	优先复制文本，不要只截日志图片
嵌入式波形、电路、设备现象	图片有明确价值，但要附上采样条件、引脚和信号说明
多页面问题	一页一张图，分别说明期望值和实际值

推荐这种图片提示词：

只分析截图中的目标区域，不要猜测未展示页面。
图片 1 是设计稿，图片 2 是当前页面。
请先列出可见差异，再修改代码。
不要任意更换颜色和间距，优先使用现有设计令牌。
修改后运行前端并截图验证。

五、从需求和架构入手，避免大面积返工

AI 最危险的使用方式，是“一句话需求直接生成一大片代码”。

更可靠的方式是：

AI 产出初版方案
-> 结合公司现有架构和实战经验完善
-> 冻结业务边界、接口和验收标准
-> 再开始开发

1. 需求输入至少包含这些内容

业务目标：
为什么现在要做：
涉及角色：
主流程：
异常流程：
数据来源：
数据去向：
权限规则：
外部系统：
性能要求：
安全要求：
兼容要求：
上线方式：
不做的范围：
验收标准：

“不做的范围”非常重要。没有明确边界，AI 很容易自行增加功能、抽象和兼容层。

2. AI 适合先产出什么

业务对象和边界。
数据流和调用链。
方案对比。
风险和遗漏点。
接口草案。
数据模型草案。
测试场景。
迁移步骤。

AI 的初版方案不能直接当作最终架构。

最终方案必须加入公司的真实约束：

已有技术栈。
已有中间件。
已有权限体系。
已有部署流程。
数据库规范。
日志和监控规范。
安全合规要求。
团队维护成本。
客户现场的实际环境。

六、把设计原则直接写进开发要求

只告诉 AI“代码要规范”，几乎没有约束力。要把原则翻译成可检查的要求。

1. SOLID 五大原则

原则	对 AI 的明确要求
单一职责	一个类或模块只承担一种变化原因
开闭原则	新功能优先通过扩展实现，不反复改核心分支
里氏替换	子类不能破坏父类已有契约
接口隔离	不强迫调用方依赖无用接口
依赖倒置	业务层依赖抽象，不直接依赖具体实现

2. 其他工程原则

Git引入，便于回退代码、找以前某时间节点的代码实现、跨机器部署。
消除真正的重复逻辑，不是把相似代码强行合并。
优先简单方案，不为不存在的需求增加复杂度。
当前不需要的扩展点不要提前实现。
高内聚、低耦合：一个模块内部紧密相关，模块之间依赖稳定。
关注点分离：UI、业务、数据访问、基础设施边界清楚。
依赖方向稳定：核心业务不要依赖界面、数据库或第三方 SDK。
组合优先于继承：用接口和组合减少继承层级。
显式契约：参数、返回值、异常、权限、错误码都要明确。
可观测性：关键链路有日志、指标和追踪。
可迁移性：数据库结构变化必须版本化。

3. 设计模式不要背名词，要说明使用条件

模式	适合解决什么
策略模式	同一业务存在多套可替换算法
工厂模式	创建过程复杂或根据配置选择实现
适配器模式	隔离第三方接口和内部模型
观察者或事件模式	模块之间需要低耦合通知
外观模式	为复杂子系统提供稳定入口
仓储模式	隔离业务层与持久化实现
工作单元	统一管理事务和聚合保存

不要默认要求 AI 使用所有模式。要求 AI 先说明问题，再说明为什么需要某个模式。

可以写成项目规则：

不要为了“以后可能扩展”创建无实际使用方的接口、工厂或抽象基类。
只有存在两个以上真实实现、明确的第三方隔离需求，或稳定扩展点时，才引入抽象。

七、不同应用类型的开发技巧

1. 客户端应用

客户端主要包括桌面端、移动端、上位机和其他带交互界面的程序。

重点约束：

UI 与业务状态分离。
网络、缓存、数据库和界面状态边界清楚。
明确状态机，避免大量零散布尔变量。
异常、重试、超时、取消和离线场景要建模。
版本升级、数据迁移和兼容策略要提前设计。
设备、权限、文件和系统 API 要经过封装。

给 AI 的要求示例：

按现有 MVVM 结构实现。
先列出页面状态、事件、命令和异常状态，再修改代码。
业务逻辑不要写进视图。
网络层保持现有接口风格，不要直接调用第三方 SDK。
补充关键状态单元测试，并说明真机验证步骤。

2. Web 前端应用

Web 前端最容易出现的问题是视觉不一致、组件重复、接口字段不一致和响应式回归。

重点约束：

先确认设计系统、组件库和颜色、间距、字号令牌。
先冻结 API 契约，再写页面。
复用已有表格、表单、弹窗和权限组件。
明确加载、空数据、错误、禁用和权限不足状态。
响应式布局使用稳定尺寸和约束，不靠随意缩放。
修改 UI 后必须运行并截图检查。

给 AI 的要求示例：

先阅读现有 UserManagement 和订单列表模块。
只复用现有组件和设计令牌，不要另建一套样式。
先输出页面结构、状态、接口依赖和组件复用清单。
修改后运行 lint、类型检查和前端构建。
最终提供桌面与移动端截图。

3. Web API 服务

Web API 是最适合 AI 参与，也最需要契约约束的类型。

开发顺序建议：

业务规则
-> 数据模型
-> OpenAPI 或接口契约
-> 权限和错误码
-> 事务边界
-> 实现
-> 集成测试
-> 可观测性

必须写清楚：

认证和授权。
参数校验。
幂等性。
分页、排序和过滤。
统一错误码。
事务边界。
并发控制。
数据迁移和回滚。
日志、指标和链路追踪。
向后兼容策略。

给 AI 的要求示例：

先根据业务规则设计接口契约，不要先写实现。
输出请求、响应、错误码、权限、分页和幂等策略。
Service 层不得直接拼接数据库查询，必须调用对应 DAO 或仓储接口。
数据库变化必须提供迁移脚本和回滚说明。
最后补充接口集成测试。

4. 嵌入式应用

嵌入式开发不能只靠模型猜。必须提供芯片、编译器、RTOS、通信协议、引脚、时序和资源限制。

重点约束：

业务逻辑与硬件抽象层分离。
中断服务程序保持短小。
明确堆栈、内存、实时性和看门狗要求。
对外协议要有帧格式、状态机和错误处理。
关键协议解析和状态机尽量在宿主机做单元测试。
硬件相关行为必须真机验证。

给 AI 的要求示例：

芯片型号、RTOS、编译器和协议手册见指定文档。
先输出状态机、消息流、超时和错误恢复方案，不写代码。
禁止在中断中执行阻塞操作。
默认不使用动态内存，若必须使用需说明理由。
业务状态机与 HAL 分离，宿主机单元测试通过后再进行硬件验证。

八、从过往项目沟通中提炼出的提示词规律

回顾我们之前围绕 ERP、Web 后台、客户端、设备程序、知识图谱、部署和方案文档的沟通，高频有效的模式主要有下面这些。

1. 先读资料，再开发

有效表达：

先阅读指定文档、现有模块和相关代码，再开始修改。
先复述你确认到的事实、依赖和风险，不要凭经验猜测。

2. 先讨论方案，不写代码

有效表达：

这一步先不要修改代码。
请先对比 2 到 3 个方案，说明优缺点、风险、回滚方式和适用条件。
等我确认方案后再实现。

3. 参照已有模块和规范

有效表达：

严格参照现有用户管理模块的目录、命名、返回结构和异常处理。
不要创建新的架构风格。
如果现有实现与规范冲突，先列出来，不要自行决定。

4. 明确不要改什么

有效表达：

允许修改 A、B、C。
不要修改数据库结构、公共接口和旧模块 D。
不要做与当前问题无关的重构。

5. 复杂业务先确认基础依赖

有效表达：

先检查该模块依赖的数据结构、权限、流程、接口和相关模块是否已经完成。
列出缺失项和风险，再开始实现。

6. 不只要修复现象，还要修复根因

有效表达：

先定位根因，不要只掩盖错误。
修复后补充能够复现原问题的测试（根据情况选择是否用AI来做测试）。
说明该问题属于单点缺陷还是同类模块的共性问题。

7. 验证结果必须可证明

有效表达：

不要只告诉我“已经完成”。
请给出实际执行命令、测试结果、未通过项和剩余风险。
没有验证的部分必须明确说明。

8. 把一次性修复变成长期规则

有效表达：

把本次问题提炼成项目规则，写入 AGENTS.md、模块文档或自动化测试，避免后续重复犯错。

九、常用提示词模板

1. 通用任务模板

你是本项目的开发负责人。

目标：

业务背景：

相关文件：

必须遵循的现有规范：

允许修改范围：

禁止修改范围：

验收标准：

验证命令：

输出要求：
1. 先说明理解与风险
2. 再执行
3. 只输出关键变更、验证结果和剩余问题
4. 不要复述背景，不要重复完整代码

2. 架构方案模板

先不要写代码。

请阅读以下文档和模块：
- docs/design/
- docs/architecture/
- 相关现有代码

输出：
1. 目标与非目标
2. 业务流程和边界
3. 数据流和调用链
4. 2 到 3 个方案对比
5. 推荐方案和理由
6. 对现有系统的影响
7. 数据迁移和回滚方案
8. 风险、遗漏点和验收标准

严格遵守公司现有技术栈，不要为了理论完整引入新框架。

3. 模块实现模板

按照已经确认的设计文档实现当前模块。

要求：
- 遵循现有目录和分层结构
- 遵循现有命名、日志、异常和返回格式
- 不修改未授权文件
- 不引入无实际使用方的抽象
- 每次修改后运行指定编译和测试命令
- 完成后检查是否影响旧功能

先输出实施步骤，然后开始执行。

4. Bug 修复模板

问题现象：

复现步骤：

期望结果：

实际结果：

相关日志：

相关文件：

要求：
1. 先定位根因，不要直接猜修复方案
2. 给出证据链
3. 修复最小范围
4. 增加回归测试
5. 检查是否存在同类问题
6. 输出修改文件、验证结果和剩余风险

5. 前端页面模板

参考现有设计系统和指定模块实现以下页面。

先输出：
- 页面结构
- 组件复用清单
- 接口依赖
- 加载、空数据、错误、禁用和权限状态
- 响应式方案

修改后：
- 运行 lint、类型检查和构建
- 启动页面并截图
- 检查移动端和桌面端
- 不得创建另一套重复组件

6. Web API 模板

先设计接口契约，不要先写实现。

输出：
1. URL 和 HTTP 方法
2. 请求与响应模型
3. 权限规则
4. 参数校验
5. 错误码
6. 分页和排序
7. 幂等策略
8. 事务边界
9. 数据库迁移与回滚
10. 集成测试场景

然后按现有分层结构实现。

7. 嵌入式模板

硬件平台：
编译器和版本：
RTOS：
相关协议：

先不要写代码。
先输出：
1. 状态机
2. 中断与主循环职责
3. 内存和栈占用估算
4. 超时和错误恢复
5. HAL 与业务层边界
6. 宿主机测试方案
7. 真机验证步骤

不得猜测硬件行为，缺少数据时必须明确列出。

8. 代码审查模板

请以严格代码审查模式检查本次变更。

优先查找：
- 行为回归
- 权限和边界错误
- 并发与事务问题
- 空值、异常和资源释放
- 安全和数据泄露
- 兼容性问题
- 缺失测试

按严重程度排序，给出文件和行号。
没有发现问题时也要说明测试缺口和剩余风险。
不要先给总结，先给发现的问题。

9. 低 Token 执行模板

直接执行当前任务。
不要复述背景，不要重复已有代码，不要输出无关方案。
只输出：
1. 变更文件
2. 关键决策
3. 实际验证结果
4. 未完成项和风险

信息足够时不要反复确认。

十、建立项目级“AI 记忆”，避免同样问题反复交互

聊天记忆不稳定，项目文件才是可靠记忆。

建议维护这些文件：

AGENTS.md
docs/architecture/
docs/adr/
docs/api/openapi.yaml
docs/database/
docs/coding-standards/
docs/prompts/
tests/

1. `AGENTS.md` 或对应工具的项目规则

内容示例：

# 开发规则

1. 修改前先阅读相关模块和设计文档。
2. 遵循现有目录、命名、日志和异常规范。
3. Service 层不得直接写数据库查询。
4. 数据库变更必须提供迁移脚本和回滚说明。
5. 公共接口必须保持向后兼容。
6. 完成后运行 lint、类型检查和对应测试。
7. 不允许执行删除数据或破坏性命令。
8. 没有验证的内容必须明确标注。

2. 架构决策记录

每个重要决定记录：

背景：
决定：
备选方案：
选择理由：
影响范围：
回滚方式：
日期：

3. 接口契约

API 字段、错误码、权限和示例统一放在契约文件中。让前后端 AI 都读取同一份契约，减少字段猜错。

4. 测试即规则

每次出现线上问题或重复缺陷，按下面流程处理：

发现问题
-> 修复根因
-> 增加回归测试
-> 提炼通用规则
-> 写入项目文档或 CI 检查

这样同一个问题才不会被不同模型、不同开发者和不同时间重复修。

十一、常见返工原因与处理方式

返工现象	根本原因	处理方式
AI 改了无关代码	修改边界不清楚	明确允许和禁止范围
新模块风格完全不同	没给现有范式	指定参考模块和代码规范
接口字段对不上	没有单一契约	先冻结 OpenAPI 和数据模型
页面反复调整	验收标准模糊	给设计稿、截图和可检查标准
抽象层越来越多	过度设计	增加 YAGNI 和真实扩展点规则
同样 Bug 反复出现	只修现象，没有沉淀	根因、测试、规则三步固定
长任务后模型失忆	上下文过长或压缩	阶段产物写入文件，及时新开对话
数据迁移出错	没有回滚和备份	迁移脚本、备份、演练和校验
“完成”其实不可运行	缺少验证闭环	必须提供命令、输出和未验证项
Token 消耗失控	上下文重复、轮次过多	相关文件、短输出、阶段拆分

十二、验证工具要优先于模型自述

模型说“已完成”，不等于结果正确。

可靠性顺序通常是：

编译器
-> 静态检查
-> 单元测试
-> 集成测试
-> 端到端测试
-> 实际运行
-> 人工审查
-> 模型解释

模型解释不能排在证据前面。

一个任务完成前，至少确认：

代码能编译。
类型检查通过。
Lint 通过。
相关测试通过。
关键路径实际运行。
旧功能没有明显回归。
数据库迁移可执行且可回滚。
日志和错误处理有效。
修改范围没有失控。
文档和接口契约已经更新。

日志模块要尽早建立

很多软件在进入复杂业务开发之前，就应该先把统一日志模块建立起来。日志不是为了上线以后才补的附属功能，而是让开发和排障可以基于运行时事实工作。

没有日志时，我们只能把大段代码和现象交给 AI，让它根据静态代码猜测问题。有日志后，AI 可以直接沿着请求链路、状态变化、耗时和错误信息定位，检查范围更小，问题更准，通常也更省 Token。

日志模块至少应包含：

统一日志级别，例如 DEBUG、INFO、WARN、ERROR。
统一时间格式和时区。
请求号、链路号或事务号。
用户、租户、模块、操作和关键业务标识。
调用阶段、依赖服务、耗时和结果。
错误码、异常类型、堆栈和上下文。
日志轮转、保留周期和导出方式。
敏感信息脱敏，禁止记录密码、密钥和完整个人数据。

示例一：Web API 接口超时

只告诉 AI“登录接口报 500，帮我猜哪里有问题”，模型通常会去检查控制器、参数、权限、数据库和缓存，范围很大，也容易连续猜测。

如果有清晰日志：

2026-09-17 10:20:31.104 INFO  requestId=8f21 user=10023 step=auth.login result=start
2026-09-17 10:20:31.108 INFO  requestId=8f21 step=auth.password.verify result=success cost=3ms
2026-09-17 10:20:34.110 ERROR requestId=8f21 step=auth.token.create dependency=redis result=timeout cost=3002ms error=RedisTimeout
2026-09-17 10:20:34.111 ERROR requestId=8f21 step=auth.login result=failed error=TokenServiceUnavailable

可以直接要求 AI：

请只根据以上日志建立时间线，区分事实和推测。
定位首个异常阶段，只读取 Token 创建和 Redis 相关代码。
先判断是超时、配置还是连接池问题，再给最小修复方案。

这样模型不需要扫描整个登录模块，排障路径也更稳定。

示例二：客户端保存操作没有反应

客户端页面点击“保存”后没有反应，可能是按钮状态、命令绑定、参数校验、接口请求、Token、超时或界面刷新问题。

如果日志能够记录完整链路：

10:35:01.020 [UI] action=Save clicked=true enabled=true
10:35:01.025 [Command] action=SaveCommand result=executed
10:35:01.031 [API] method=PUT url=/api/orders/1008 result=start requestId=71ac
10:35:01.104 [API] method=PUT url=/api/orders/1008 status=401 error=TokenExpired requestId=71ac
10:35:01.108 [Auth] action=RefreshToken result=failed error=RefreshTokenMissing
10:35:01.109 [UI] action=Save result=failed visibleMessage=false

AI 可以准确看到：按钮和命令执行了，真正的问题是 Token 刷新失败，而且失败信息没有展示给用户。它不需要先怀疑界面绑定，也不会把时间浪费在无关的 MVVM 代码上。

示例三：嵌入式设备通信失败

嵌入式问题如果只给一段驱动代码，模型很难判断是协议、时序、缓冲区、硬件还是对端设备问题。串口或调试日志能直接提供状态机运行轨迹：

tick=1200 state=IDLE event=START result=enter
tick=1201 state=SEND txFrame=01 03 00 00 00 02 crc=7B4A result=success
tick=1202 state=WAIT_ACK timeout=500ms
tick=1703 state=WAIT_ACK event=TIMEOUT retry=1
tick=2205 state=WAIT_ACK event=TIMEOUT retry=2
tick=2707 state=ERROR error=ACK_TIMEOUT

模型可以围绕发送成功、等待超时、重试次数和链路状态分析问题，而不是同时猜测所有驱动代码。下一步只需要结合示波器、线序、波特率和从机响应继续验证。

示例四：业务流程状态不正确

审批、订单、生产流程这类业务，如果没有状态流转日志，AI 很容易根据页面现象猜错模块。有效日志应记录：

docId=PO20260917001 event=SUBMIT from=DRAFT to=APPROVING user=10023
docId=PO20260917001 event=REJECT from=APPROVING to=REJECTED user=10031 reason=amount
docId=PO20260917001 event=QUERY displayStatus=APPROVING source=cache

此时可以直接判断，数据库中的状态流转可能是正确的，页面显示异常来自缓存或展示映射。AI 检查范围会从整个审批模块缩小到状态查询和缓存刷新。

最后我们的目标：尽可能节省Token、少返工、还能高效完成可扩展的产品级应用。

一、先看一个核心公式

二、工具选择：不要只用最强模型，要做模型路由

1. 第一原则：按任务风险路由

2. 第二原则：在一个任务边界内尽量不频繁换模型

3. 第三原则：让模型之间通过文档交接，而不是通过聊天记忆交接

三、如何真正减少 Token 使用量

1. 不要整仓库塞给模型

2. 上下文只保留完成任务必需的信息

3. 控制输出形式

4. 把长任务切开

5. 在正确的时候新开对话

6. 利用稳定的项目前缀

四、图片交互会增加 Token 吗

五、从需求和架构入手，避免大面积返工

1. 需求输入至少包含这些内容

2. AI 适合先产出什么

六、把设计原则直接写进开发要求

1. SOLID 五大原则

2. 其他工程原则

3. 设计模式不要背名词，要说明使用条件

七、不同应用类型的开发技巧

1. 客户端应用

2. Web 前端应用

3. Web API 服务

4. 嵌入式应用

八、从过往项目沟通中提炼出的提示词规律

1. 先读资料，再开发

2. 先讨论方案，不写代码

3. 参照已有模块和规范

4. 明确不要改什么

5. 复杂业务先确认基础依赖

6. 不只要修复现象，还要修复根因

7. 验证结果必须可证明

8. 把一次性修复变成长期规则

九、常用提示词模板

1. 通用任务模板

2. 架构方案模板

3. 模块实现模板

4. Bug 修复模板

5. 前端页面模板

6. Web API 模板

7. 嵌入式模板

8. 代码审查模板

9. 低 Token 执行模板

十、建立项目级“AI 记忆”，避免同样问题反复交互

1. AGENTS.md 或对应工具的项目规则

2. 架构决策记录

3. 接口契约

4. 测试即规则

十一、常见返工原因与处理方式

十二、验证工具要优先于模型自述

日志模块要尽早建立

示例一：Web API 接口超时

示例二：客户端保存操作没有反应

示例三：嵌入式设备通信失败

示例四：业务流程状态不正确

推荐排障提示词

发表评论 取消回复

1. `AGENTS.md` 或对应工具的项目规则

发表评论取消回复