让 AI 改了半天，方向全错了？

• 让 AI 改了半天代码，最后发现方向全错了？
• 上下文越来越长，AI 开始前言不搭后语？
• 换了个新工具，感觉和以前没什么区别？

根因：工具链断裂

旧工作流

打开网页 → 粘贴代码 → 复制结果 → 手动修改 → 再开新窗口...

新工作流

AI 在 IDE 里 → 直接看你的代码 → 自己跑命令修错误 → 内网同步一行 git pull

本次目标

• 打通工具链：从工具选型到跨区同步
• 学会用好它：架构师思维 + 实战技巧

核心观点

从 "写好代码" → "做好设计"

新角色定位：架构师思维

正确工作流

明确目标 → 输出设计方案 → 扮演挑战者评审方案 → 细化实施计划 → 交给 AI 执行

反例（呼应开篇）

"直接让 AI 写代码 → 改了半天 → 发现方向全错"
—— 问题不在 AI，在于缺少设计阶段

硬件方案

跨区代码同步

外网机开发 → git push 私有仓库 → 内网机 git pull

可配合 rsync 自动上传服务器

AI 编程工具选型

为什么推荐 Antigravity

项目背景

• 功能：基于气象数据预测日照金山、云海、观星、雾凇等自然景观出现概率
• 技术栈：Python 后端 + Vue 3 前端 + 高德地图 + ECharts

技巧一：文档优先

先完成设计方案文档，不急着写一行代码

实际做法：先花 3 天写设计文档

2026-02-09  v1.0 — 初版文档（1份 .md）
2026-02-10  v2.0 — 全面重写：ER图、评分一致性、ScoreEngine注册机制
2026-02-10  v3.0 — 架构重构：可插拔 ScorerPlugin 体系
2026-02-12  v4.0 — 最终对齐，移除并发，明确同步架构
2026-02-12  ✅ 开始写第一行代码

设计文档目录（12 个 .md）

design/
├── 01-architecture.md       # 系统架构、数据流
├── 03-scoring-plugins.md    # 可插拔 Plugin 架构
├── 06-class-sequence.md     # 类图、时序图（UML）
├── 10-frontend-A/B/C.md     # 前端三个方案并行设计
└── ...（共 12 个）

技巧二：扮演挑战者迭代设计

对方案的架构、时序图、组件关系不断提问和质疑
目标：把方案逼到经得起推敲才算完成设计

GMP 实际挑战到的问题

设计细节举例：云量的一票否决

挑战者提问："云量 30% 和 90% 对景观的影响是线性的吗？"

• → 不是，所以引入了一票否决：目标峰云量 > 50% 直接得 0 分
• → 这种设计如果不先思考，写完代码再改会很痛

技巧三：上下文主动切分

单个会话过长 → AI 丢失重要信息

GMP 实施计划拆分粒度

M01-project-init.md
M02-data-models-exceptions.md
M09A-plugin-cloud-sea.md        ← 云海插件
M09B-plugin-frost.md            ← 雾凇插件
M10A-plugin-golden-mountain.md  ← 日照金山插件
M10B-plugin-stargazing.md       ← 观星插件
... (共 30+ 个)

AI 的注意力就像手电筒，你给的输入越精准，它照的越准。

技巧四：分阶段开发

设计方案 → 实施计划编写 → 代码开发（/impl）→ 代码检视（/check-impl）

开发阶段只看实施计划，不看设计讨论过程
→ 减少上下文噪音，AI 更专注

AI 检视报告节选

✅ 与实施计划一致性：完全一致
✅ 与设计文档一致性：完全一致（§11.4 reject_reason 字段定义）
✅ 测试覆盖：覆盖计划中列出的全部测试点
⚠️ [Low] 建议补充 breakdown 全部 max=0 的边界测试用例
整体结论：✅ 通过

"这份报告不是我写的，是 AI 拿着文档自己写出来的——这是「让 AI 监督 AI」"

GMP 成果数字

挑战：如何高效读懂陌生项目

推荐工作流

工具链串联的价值

网页 AI 的调研广度 + 本地 AI 的代码精准度，两者互补

AgentScope 深度洞察报告

项目规模：2年演进历史（v0.0.1 → v1.0.0），跨越 Alibaba 内部孵化到开源，数千次提交

AI 一次性梳理出的结构（342行报告）：

✅ 项目定位：面向开发者的多智能体编程框架（AOP范式）
✅ 核心架构：4大基础模块（Message / Model / Memory / Tool）
✅ 核心范式：ReAct 智能体工作流
✅ 分布式 Runtime：Engine + Sandbox 双引擎架构
✅ 评估体系：GeneralEvaluator → RayEvaluator（分布式生产）
✅ 生态集成：LangChain Adapter / MCP 协议 / Mem0 长期记忆

核心技巧：探索模式问法

❌ 错误问法："AgentScope 的 Memory 怎么用？"

AI 会给你一份 API 使用说明，等同于直接看文档

✅ 正确问法（探索模式）：
"AgentScope 的 Memory 和普通的 Chat History 有什么本质区别？它的设计到底在解决什么问题？"

AI 分析出的双控制模式

开发者控制（Session 级）
record / retrieve — 系统性管理生命周期

智能体控制（Runtime 级）
record_to_memory / retrieve_from_memory — 供 Agent 在推理过程中自主决策

为什么回答这么准？
导出的文档包含了官方架构说明和代码示例，AI 有依据，不是在猜

Tip 1：引导 AI 的两种模式

探索模式（不熟悉的领域）

定向模式（有明确方案后）

真实案例：GMP 前端架构选型（探索模式）

背景：我对前端开发完全陌生，不知道该选什么架构

❌ 错误问法（带有倾向性引导）：
"帮我用地图做前端，按照高德地图的方式"

✅ 正确问法（探索模式）：
"我需要一个前端界面，展示川西 46 个观景台的景观预测分数。用户群是手机端旅行者，需要方便截图发朋友圈。请给我几个候选架构方案。"

AI 给出 3 套并行方案

→ 最终选择了方案A（沉浸地图），因为地图总览图天然适合发朋友圈

如果一开始就说"用地图做"，AI 只会给出一套方案。探索模式让我看到了我根本不知道存在的 B、C 方案。

Tip 2：做工具的使用者，不是被工具带着走

新旧思维对比