01一个完美架构的诞生与死亡1.1 我们最初的野心故事要从几周前说起。那时候团队刚开始系统性地探索 AI 辅助开发。我们读了大量论文和博客看到业界在讨论多智能体协作、“Agent 编排”、“知识图谱”……我们想既然要做就做一套正经的架构。于是我们设计了这样一套系统用户需求 ↓ ┌───────────────────────────────────────────────────────┐ │ Command 层入口 │ │ /req-dev启动研发流程 │ └───────────────────────────────────────────────────────┘ ↓ ┌───────────────────────────────────────────────────────┐ │ Agent 层决策 │ │ phase-router → 意图识别 → 路由到专业 Agent │ │ ├── design-manager设计管理 │ │ ├── impl-coordinator实现协调 │ │ └── experience-depositor经验沉淀 │ └───────────────────────────────────────────────────────┘ ↓ ┌───────────────────────────────────────────────────────┐ │ Skill 层执行 │ │ req-create, workspace-setup, meta-maintainer... │ └───────────────────────────────────────────────────────┘我们还定义了严格的九步工作流需求录入 → 上下文准备 → 方案设计 → 设计评审 → 代码实现 → 代码审查 → 测试验证 → 经验沉淀 → 需求关闭。每一步都有专门的 Agent每个 Agent 都有专门的 Skill一切井井有条。我们甚至为 Agent 之间的通信设计了标准的 JSON 协议为元信息管理写了专门的维护脚本。1.2 第一个裂缝架构设计完成后我们试着在脑子里“走一遍流程”。假设我想改一个配置文件里的默认值。按照我们的设计我应该创建一个“微需求”等待 phase-router 识别意图被路由到impl-coordinator初始化标准的工作空间然后才能改那一行代码想象中我将花 15 分钟走完流程只为改 1 秒钟的代码。我当时想可能是因为这个需求太小了不适合用完整流程。于是我又试想了一个“正经”的需求——给服务加一个新接口。这次流程在脑子里走得更顺畅了。但我开始担忧一些问题如果真的实现这套架构我花在“让 AI 理解流程”上的精力会不会比花在“让 AI 理解业务”上的还多phase-router 可能会误判意图需要手动纠正。Agent 之间的上下文传递可能会丢失关键信息。元数据维护也可能出问题。1.3 一个诚实的问题就在我们讨论架构设计的间隙我需要完成一个小任务。我直接在聊天框里写“帮我在 user 表加一个 last_login_at 字段datetime 类型默认 null然后在登录接口里更新它。”AI 直接帮我完成了。没有走任何流程没有创建需求 ID没有初始化工作空间。5 分钟完事。那一刻我问自己一个问题如果按照我们设计的架构来做这个任务效率会更高还是更低这个问题让我很不舒服。因为它意味着我们过去几天的设计工作可能是无效的。1.4 回到原点的勇气我把这个困惑分享给团队。讨论了很久之后我们决定做一件需要勇气的事暂停所有架构开发重新思考 AI 工程化到底应该是什么。我们问自己三个问题我们到底在解决什么问题 —— AI 辅助开发的效率和质量现有架构解决了吗 —— 没有反而增加了认知负担有没有更简单的方案 —— 不知道需要重新调研带着这三个问题我们开始了新一轮的探索。02两个产品的启发转折点来自两个看似不相关的产品Google 的 NotebookLM 和 Anthropic 的 Claude Code。2.1 NotebookLM简单到让人惭愧在准备团队分享时我用 NotebookLM 整理资料。把几篇论文和博客丢进去它就能帮我总结要点、回答问题、生成播客。然后我注意到这个产品的界面——简单到让人惭愧。┌──────────────────────────────────────────────────────────────────────────┐ │ NotebookLM │ │ │ │ 左栏来源 │ 中栏对话 │ 右栏输出 │ │ ───────────── │ ───────────── │ ───────────── │ │ 添加来源 │ [AI 自动总结] │ 思维导图 │ │ ☐ PDF │ 推荐问题 │ 播客 │ │ ☐ 网页 │ • ... │ 报告 │ │ ☐ 视频 │ • ... │ ... │ │ ☐ 笔记 │ │ │ │ │ [输入框] │ │ └──────────────────────────────────────────────────────────────────────────┘就这就这没有智能路由没有多 Agent 协作没有知识图谱。就是来源 对话 输出三栏设计。但它解决了一个核心问题让人能快速消化大量信息。我开始思考NotebookLM 的设计逻辑是什么输出 f(来源, 输出格式) 其中 - 来源你丢进去的材料 - 输出格式播客、报告、思维导图... - fLLM 的理解和生成能力这个公式简单到不需要任何架构。 你只需要把材料组织好告诉 AI 你想要什么格式的输出我们的三层架构、九步工作流本质上是在 f 这个函数上做文章试图让它更智能。但 NotebookLM 告诉我们f 已经够强了问题在于如何组织好输入。2.2 Claude Code反直觉的极简主义如果说 NotebookLM 是一个启发Claude Code 就是一记重锤。Anthropic 发布 Claude Code 时我花了一整个周末研究它的设计理念。有几点让我印象深刻第一他们也曾想做复杂架构然后放弃了。“一开始 Claude Code 就能给自己创建和使用工具。我们试图在后台创建一个复杂的工具图……我们做的越多它就变得越不可靠。”听起来熟悉吗我们也在做复杂的工具图。第二他们选择了最小化工具数量。“你给模型的工具越少每次调用的效率就越高……与其创造很多小的、精确的工具不如创造大的、表达力强的工具然后信任模型。”我们的做法正好相反——我们设计了 req-create、workspace-setup、meta-maintainer 等一堆精细的 Skill。第三Claude Code 创作者的实际工作方式印证了这一点。Claude Code 创作者分享过他的使用经验他几乎不做复杂的定制而是依靠最基本的能力——同时运行 10-15 个 Claude 实例每个处理一个独立任务每周产出 50-100 个 PR。这个数字让我们反思我们花那么多时间设计完美架构是不是本末倒置了第四他们强调完全的能力对等。“你能做的事情Claude 都能做。”我们的九步工作流实际上是在限制 AI 的能力——它必须按照我们规定的路径走。第五最让我震撼的一句话“最好的工具是你不知道它存在的工具。”我们的架构不是在创造工具而是在创造流程。用户每次使用都能感受到流程的存在这本身就是失败。2.3 核心洞察文本是通用接口两个产品给我们的共同启发是LLM 本身就是最好的解释器它不需要复杂的协议。NotebookLM 直接读 PDF 和网页。Claude Code 直接操作文件系统。它们都没有中间层的意图识别或路由调度。回到我们的场景——代码开发本质上也是信息处理代码 LLM(业务需求 技术规范 项目约定 历史经验)既然如此我们需要做的不是设计复杂的 Agent 编排而是把业务需求、“技术规范”、“项目约定”、历史经验组织成 LLM 能理解的格式。什么格式Markdown。 最朴素的文本格式。03认知转变从代码到文本这次探索带来了一个根本性的认知转变。3.1 旧思维 vs 新思维维度旧思维新思维如何让 AI 遵循规范开发工具强制执行写成提示词让 AI 理解如何管理 AI 状态设计元数据系统保存到文件下次读取如何沉淀经验开发经验管理 Agent写文档放到 context 目录如何路由意图开发路由 Agent在提示词里写清楚决策逻辑核心观点你不需要为 AI 开发复杂的工具你只需要把知识结构化地写下来。3.2 一个具体的例子假设我们有一个规范提交代码前必须运行 lint 检查。旧做法开发一个 pre-commit Skill → 在 impl-coordinator Agent 里调用 → 检查失败时返回特定错误码 → Agent 根据错误码决定下一步新做法# AGENTS.md ## 代码提交规范 - 提交前必须运行 make lint - lint 不通过不要提交先修复问题就这样。AI 会自己读这段话自己执行 lint自己修复问题。不需要任何代码。3.3 这不是偷懒这是更高效的工程有人可能会说这不就是把复杂度藏到提示词里了吗不是的。提示词和代码的本质区别在于提示词是声明式的代码是命令式的。声明式告诉 AI “应该是什么样”命令式告诉 AI “应该怎么做”当你用代码实现一个流程你需要考虑所有边界情况、错误处理、状态管理。当你用提示词描述一个规范AI 会自己处理这些细节。这不是偷懒这是利用 LLM 的能力来降低工程复杂度。04落地哲学三个核心原则基于上述反思我们提炼出三个落地原则。原则一文档即记忆Dual UseAGENTS.md 既是新人的入职手册也是 AI 的核心记忆。这个原则的精妙之处在于同一份文档人类和 AI 都能读懂、都能用。 你不需要维护两套知识体系——一套给人看一套给 AI 用。当你写文档时想象你在给一个聪明但对项目一无所知的新同事讲解。这个新同事可能是人类也可能是 AI。原则二先跑起来从最简单的提示词开始让 AI 辅助工作能用。不要追求完美设计先让流程转起来。一个能用的简单系统好过一个完美但用不起来的复杂系统。我们的错误正是在系统能用之前就开始追求完美。Claude Code 创作者的计划模式工作流印证了这一点“大多数会话都从计划模式开始。与 Claude 来回讨论直到满意其计划然后切换到自动接受编辑模式。Claude 通常可以一次完成。一个好的计划非常重要。”注意这里的关键不是设计复杂的计划 Agent而是用对话的方式讨论计划确认后再执行。简单、直接、有效。原则三自然演进观察团队如何使用甚至滥用工具将高频模式固化为能力。不预设复杂架构让需求驱动演进。Claude Code 团队有一句话说得很好“构建一个足够开放的产品观察人们如何’滥用’它然后为此而构建。”不要试图预测用户需要什么。先给他们一个简单的工具看他们怎么用再决定要不要封装。05最简起点一个文件搞定5.1 只需一个文件忘掉复杂的架构。在项目根目录创建 AGENTS.md# AGENTS.md ## 项目背景 这是 xxx 项目使用 Go MySQL核心服务包括用户服务和订单服务。 ## 工作规范 - 先读代码再改不要猜测未检查的代码 - 代码注释用中文变量命名用英文 - 不确定的地方问我不要自己瞎猜 ## 常见坑点 遇到问题再补充这就是全部起点。 启动 AI 工具它会自动读取这个文件开始工作。5.2 提示词的自然演进随着使用提示词会自然生长。以下是一个典型的演进路径起步阶段基础背景## 项目背景 微服务架构Go 语言核心服务有用户服务、订单服务。积累阶段补充踩过的坑## 常见坑点 - Apollo 配置格式key 必须是 xxx.yyy.zzz 三段式 - 数据库连接测试环境 IP 是 10.0.0.1不是 localhost - 商品发放虚拟商品发到虚拟钱包实物商品发到实体钱包成熟阶段形成知识索引## 关键知识 详细的技术背景见 context/ 目录 - 服务架构context/tech/services/ - 业务逻辑context/business/ - 历史经验context/experience/关键不要一开始就设计完美的知识结构。遇到什么记什么自然演进。5.3 提示词设计的实用技巧技巧 1用 XML 标签隔离不同类型的指令coding_style dos - 错误处理必须包装fmt.Errorf(failed to x: %w, err) - 日志必须带 traceId /dos donts - 禁止使用 panic - 禁止在循环中调用数据库 /donts /coding_style技巧 2写决策逻辑而不是散乱的规则## 遇到不确定的业务逻辑时 1. 先搜索 context/business/ 下的相关文档 2. 如果文档没写搜索相关代码实现 3. 如果代码也不明确再问我技巧 3记录 AI 容易犯的错每次 AI 犯错后把纠正内容加入 AGENTS.md## AI 注意事项 - 【重要】修改 config 后要重启服务才能生效 - 【重要】用户表的 status 字段0未激活1正常2封禁不是布尔值这是最低成本的模型微调——记一次终身受益。技巧 4简单的自然语言指令比复杂工具更有效你想要的效果直接说AI 不确定时问你“有不清楚的就问我”AI 先想清楚再动手“先想想方案再动手”简化冗长的代码“简化一下”深度思考复杂问题“Think” 或 “仔细想想”5.4 何时需要封装成工具判断标准如果在 AGENTS.md 里写几句话就能达到同样效果那就不需要封装。场景是否需要封装需要特定领域知识如服务代码分析框架✅ 是流程复杂且固定如发布流程、安全检查✅ 是自然对话能完成需求澄清、方案讨论❌ 否只是提示词优化❌ 否Claude Code 创作者的经验只为内部循环封装工具“我为每天多次执行的’内部循环’工作流使用斜杠命令。避免重复提示Claude 也可以使用这些工作流。”他的 /commit-push-pr 命令每天使用数十次这种高频操作才值得封装。而且命令使用内联 bash 预计算 git status 等信息“使命令运行快速避免与模型来回交互”。另一个实用技巧用 Hook 处理格式化“我们使用 PostToolUse hook 格式化 Claude 的代码。Claude 通常开箱即用生成格式良好的代码Hook 处理最后 10% 的格式化避免后续 CI 中的格式化错误。”这是把复杂度交给自动化的好例子——不需要在提示词里反复强调格式规范用 Hook 自动处理。06解决 AI 失忆问题6.1 核心问题AI是无状态的AI 的记忆只存在于当前对话窗口。会话结束记忆清空。这就是为什么昨天告诉它的注意事项今天又忘了做到一半的任务换个会话就不知道进度了这是 LLM 的本质特性而不是产品缺陷。 理解这一点很重要。大模型本质上是一个无状态的纯函数。它随时可以处理任何需求前提是你必须恢复它的内存上下文。解决方案把记忆保存到文件新会话时从文件恢复。会话内存易失 文件系统持久 ↓ ↓ 当前思维状态 ──保存──→ process.txt ↑ ↓ 新会话开始 ←──恢复── process.txt6.2 保存与恢复进度在会话结束前让 AI 把当前状态保存到文件# process.txt ## 当前状态 正在开发用户认证功能API 已完成下一步是写单元测试。 ## 已完成 - [x] 设计 JWT Token 结构 - [x] 实现登录接口 - [x] 实现 Token 校验中间件 ## 待完成 - [ ] 编写单元测试 - [ ] 处理 Token 刷新逻辑 ## 注意事项 - Token 过期时间配置在 config/auth.yaml - 测试时需要先启动 Redis新会话开始时让 AI 读取这个文件它就能恢复上下文已读取过程文件。上次停在编写单元测试。 当前环境已检查 - Git 状态干净最后提交是feat: 实现 Token 校验中间件 - Redis需要启动 是否继续编写单元测试就像游戏的存档/读档机制——会话切换变得无缝。6.3 长期任务的最佳实践Anthropic 的研究指出了两种常见的失败模式失败模式症状解决方案一次性完成试图一口气完成所有功能上下文耗尽后留下半成品一次只做一个功能做完就提交过早宣布胜利看到部分功能完成就认为任务结束用功能清单跟踪全部完成才算完成功能清单的关键作用对于复杂任务创建 features.json{ requirement_id: example-requirement, features: [ { id: F001, name: 用户登录, description: 实现用户登录功能, priority: 1, status: done, estimated_effort: 2h, actual_effort: 2h, dependencies: [], acceptance_criteria: [AC-001], related_files: [src/login.ts], review_status: approved }, { id: F002, name: Token 刷新, description: 实现 Token 刷新能力, priority: 2, status: in_progress, estimated_effort: 2h, actual_effort: null, dependencies: [F001], acceptance_criteria: [AC-002], related_files: [src/refresh.ts], review_status: null } ], summary: { total: 2, done: 1, in_progress: 1, pending: 0 } }关键约束AI 只能修改执行态字段status/actual_effort/review_status/summary/last_updated 等禁止删改功能点定义性字段以 context/project/AgenticMetaEngineering/design/元工程规范/资源/结构示例/features.json.example 为唯一口径避免口径漂移与“偷懒跳过功能”。6.4 高级技巧利用独立上下文进行自我审查Claude Code 团队发现了一个反直觉的现象“价值往往不在于角色扮演而在于不相关的上下文窗口。”当你完成一段复杂的代码后不要在同一个会话中让 AI review。因为此时的上下文已经被污染了——它包含了之前的试错、假设和偏见。最佳实践提交代码保存进度开启一个全新的会话让新会话的 AI 对刚才的改动进行审查两个互不知道对方上下文的窗口往往能发现明显的逻辑漏洞。这就像找了另一个同事来做 Code Review。6.5 最重要的技巧给 AI 一个验证其工作的方式Claude Code 创作者在分享他的经验时特别强调“这可能是从 Claude Code 获得出色结果的最重要的事情——给 Claude 一种验证其工作的方式。如果 Claude 有这个反馈循环它会将最终结果的质量提高 2-3 倍。”不同场景的验证方式开发场景验证方式后端 API运行测试套件、curl 调用接口前端 UI浏览器预览、截图对比配置变更重启服务验证配置生效移动应用iOS/Android 模拟器测试关键洞察“实际上非常简单我认为人们有时会把它过度复杂化。给 Claude 一个查看代码输出的工具告诉 Claude 关于这个工具。就是这样。Claude 会自己弄清楚其余的部分。”这印证了我们的核心观点不需要复杂的架构只需要给 AI 正确的能力和明确的指引。07团队共享单仓库模式7.1 为什么用单仓库既然大模型是无状态函数那么团队其实不需要50 个 Agent 实例只需要1 个 Agent 工程 50 个独立的上下文空间。这里说的单仓库有两层含义第一层团队共享同一套 AI 配置知识层面传统做法是每个人各自维护自己的 AI 配置——你的 CLAUDE.md 和我的 CLAUDE.md 完全不同。问题是你踩过的坑我不知道好的提示词技巧无法共享团队知识变成孤岛单仓库的解法把 CLAUDE.md、context/、.codebuddy/ 等 AI 配置文件统一放在一个 Git 仓库里团队成员通过 clone 这个仓库获得完全一致的 AI “记忆”。第二层并行工作时的隔离执行层面Claude Code 创作者的实践验证了这一点“我在终端中并行运行 5 个 Claude。我使用同一仓库的 5 个独立 git checkout。”关键在于每个 checkout 都包含相同的 CLAUDE.md 和团队知识因为都是从同一个仓库 clone 的但各自在独立的分支上工作互不干扰。团队共享仓库master ├── CLAUDE.md ← 所有人共用的 AI 记忆 ├── context/ ← 所有人共用的知识库 └── .codebuddy/ ← 所有人共用的工具 开发者 A 的 checkout 开发者 B 的 checkout 开发者 C 的 checkout ├── (继承 master) ├── (继承 master) ├── (继承 master) ├── feature/auth ├── feature/payment ├── bugfix/login └── 独立的工作空间 └── 独立的工作空间 └── 独立的工作空间这样实现了知识共享大家的 AI 都知道同样的事情 工作隔离各自的代码改动不会冲突。总结——传统模式 vs 单仓库模式维度传统模式单仓库模式AI 配置每人各自维护 → 知识孤岛统一工程所有人共用一套 AGENTS.md踩坑经验你踩过的坑同事不知道 → 重复踩坑记录到 context/通过 PR 共享给所有人好的实践只能口头传授Git 版本管理合并到 master 瞬间分发并行工作容易冲突独立分支隔离互不干扰7.2 目录结构AgenticMetaEngineering/ ├── AGENTS.md # AI 的入职手册最重要 ├── context/ # 团队知识库 │ ├── team/ # 团队通用知识 │ └── project/ # 项目特定知识 ├── requirements/ # 需求记录Git 管理 │ └── {requirement-id}/ ├── workspace/ # [废弃] 占位目录实际工作区迁移至 ../workspace/ │ └── {requirement-id}/ └── .codebuddy/ └── commands/ # 自定义命令7.3 分支策略master模板保持干净 ├── AGENTS.md # 团队共享的提示词 ├── context/ # 团队共享的知识库 └── .codebuddy/ # 团队共享的工具 feature/your-work你的工作分支 ├── 继承 master 全部内容 ├── requirements/ # 你的需求记录 └── ../workspace/ # 你的代码与本仓库同级核心原则master 是模板不直接在上面工作创建分支开始需求开发好的实践通过 PR 合并回 master所有人受益7.4 上下文检索为什么不需要 RAG很多人第一反应是要不要用向量数据库做 RAG——答案是不需要。Claude Code 团队最初也尝试过向量 embeddings但发现了问题维护成本高需要持续重建索引本地文件修改后难以实时同步安全风险独立的向量数据库增加了攻击表面积检索准确率对于代码库这种结构化数据简单的语义搜索往往不如 Agent 主动探索精准我们的方案直接给 AI 赋予 grep、find、ls 能力。它能像资深工程师一样通过文件结构和关键词自己找到答案。组织原则按领域分文件夹tech/、business/、experience/文件名要清晰让 ls 出来的列表就有语义内容是 Markdown最自然的文本格式7.5 知识路由表信息类型放哪里示例新人必读的项目背景AGENTS.md“本项目使用 DDD 架构”踩坑经验context/experience/“Apollo 配置本地需要加 -Denvdev”业务逻辑规则context/business/“VIP 用户提现额度计算规则”整体计划plan.md“designing 完成后进入 developing”当前任务进度process.txt“API 完成下一步写测试”已确认关键发现notes.md“JWT exp 使用 UTC 时区需要注意转换”未确认临时记录process.txt“发现 User 表有个字段没用待确认”决策口诀是整体计划→ plan.md是当前进度→ process.txt是长期知识所有人都得知道→ AGENTS.md特定领域→ context/ 目录08复合工程让每次实践产生复利8.1 复合工程的核心理念回到文章开头的问题我们走了那么多弯路有什么价值价值在于这些弯路本身可以被记录下来成为团队的共享知识。这就是复合工程的核心理念让每一单元的工程工作使后续工作变得更容易而非更难。Claude Code 创作者的团队正是这样做的“我们团队为 Claude Code 仓库共享单个 CLAUDE.md。将它检入 git整个团队每周贡献多次。每当看到 Claude 做错什么就添加到 CLAUDE.md这样 Claude 下次就知道不要那样做了。”这是最朴素但最有效的复合工程——把纠错变成资产。第 1 次做支付需求45 分钟 → 记录坑点 第 2 次做支付需求20 分钟 → AI 自动提醒 第 n 次做支付需求5 分钟 → 知识已编码进系统8.2 最简的复合工程实践记录即工程。不需要复杂的架构只需要一个习惯每次遇到问题解决后 → 花 2 分钟记录 记录到哪里→ AGENTS.md 或 context/ 记录什么→ 问题、原因、解决方案示例# context/experience/商品发放-钱包问题.md ## 问题 商品发放到错误的钱包类型 ## 原因 虚拟商品和实物商品的钱包不一样 ## 解决方案 根据 goods_type 判断 - virtual → virtual_wallet - physical → physical_wallet8.3 三层迭代循环第一层日常开发循环每天遇到问题 → 解决 → 记录到 AGENTS.md 或 context/第二层周期整理循环每周Review 本周记录 → 整理归类 → 提交 PR → 团队 Review → 合并到 master第三层能力固化循环每月识别高频模式 → 讨论是否封装 → 创建 Command/Skill → 团队共享8.4 通过 PR 共享经验好的实践不要藏着通过 PR 合并到 master全团队受益。Claude Code 创作者的团队更进一步他们在代码审查期间直接通过 .claude 标记让 AI 作为 PR 的一部分向 CLAUDE.md 添加内容。这是用 CI 自动化经验沉淀的绝佳示例。示例 PR## PR 标题 add: 商品发放钱包选择经验 ## 变更内容 - 新增 context/experience/商品发放-钱包问题.md ## 背景 开发 xxx 需求时发现虚拟商品和实物商品的钱包配置不同 多次踩坑后整理成文档。09团队推广9.1 不要强推用效果说话错误做法开会宣布以后大家都要用 AI 工程化正确做法先自己用起来展示实际效果“这个需求我只花了 10 分钟因为 AI 帮我避开了 3 个坑”分享你的配置让感兴趣的同事也试试9.2 分级推进阶段参与者目标试点1-2 个种子用户验证流程可行积累初始 context扩展感兴趣的同事补充更多经验形成正反馈全员整个团队成为日常工作方式9.3 避免常见陷阱陷阱症状解决方案过度流程化PR 审核变成形式主义简化 Review 标准快速合并只有少数人参与大部分人从不提 PR降低门槛鼓励小贡献context 膨胀失控文件太多找不到定期清理过时文档知识过时不更新老文档误导人遇到问题时顺手更新10回顾与反思10.1 我们学到了什么关于架构复杂的 Agent 编排不是必需的简单的提示词往往更有效不要预设架构让需求驱动演进文本是最好的接口LLM 能直接理解 Markdown关于产品思维最好的工具是你感觉不到它存在的工具先让系统能用再让它好用观察用户如何滥用你的产品那里有真正的需求关于团队协作知识要流动孤岛是效率的敌人每次踩坑都是沉淀经验的机会用效果说话不要强推10.2 Workflow vs Agent再次辨析回顾 Anthropic 的 Building Effective AI Agents我们对 Workflow 和 Agent 的边界有了更清晰的理解概念定义适用场景Workflow预定义的代码路径确定性任务步骤固定AgentLLM 动态决策的过程开放性任务需要灵活判断判断是否需要 Agent 的三个问题问题答案 → 方案任务步骤是否可预先定义是 → 用 Workflow是否需要根据中间结果灵活调整是 → 用 Agent能否用单次 LLM 调用解决是 → 先优化 Prompt我们最初的错误是用僵化的 Workflow九步工作流来约束本应灵活的 Agent。10.3 还有什么没想清楚诚实地说有些问题我们还没有答案如何衡量 AI 工程化的 ROI 我们能感觉到效率提升但很难量化context 的最佳组织方式是什么 目前是按领域分但可能有更好的方式团队规模增大后如何避免 context 混乱 我们还在探索如果你有好的想法欢迎讨论。11总结我们的核心认知转变从精密设计到最简起点从代码实现到文本描述从个人使用到团队共享AI 工程化的本质把 AI 当成团队的新成员来培养——给它入职手册AGENTS.md教它项目知识context/让它记住经验process.txt最终成为团队的共享能力。落地三原则文档即记忆 —— AGENTS.md 是人机共用的入职手册先跑起来 —— 从最简单的提示词开始自然演进 —— 观察使用模式让需求驱动演进最后想说的是AI 工程化没有银弹。这篇文章记录的是我们的探索路径不是唯一正确的答案。你的团队、你的项目、你的场景可能完全不同。但有一点是通用的先让它跑起来在实践中迭代。如果你也在探索 AI 工程化希望我们的弯路能给你一些参考。也欢迎分享你的经验——这正是复合工程的精神让每个人的实践成为所有人的财富。最后唠两句为什么AI大模型成为越来越多程序员转行就业、升职加薪的首选很简单这些岗位缺人且高薪智联招聘的最新数据给出了最直观的印证2025年2月AI领域求职人数同比增幅突破200% 远超其他行业平均水平整个人工智能行业的求职增速达到33.4%位居各行业榜首其中人工智能工程师岗位的求职热度更是飙升69.6%。AI产业的快速扩张也让人才供需矛盾愈发突出。麦肯锡报告明确预测到2030年中国AI专业人才需求将达600万人人才缺口可能高达400万人这一缺口不仅存在于核心技术领域更蔓延至产业应用的各个环节。那0基础普通人如何学习大模型 深耕科技一线十二载亲历技术浪潮变迁。我见证那些率先拥抱AI的同行如何建立起效率与薪资的代际优势。如今我将积累的大模型面试真题、独家资料、技术报告与实战路线系统整理分享于此为你扫清学习困惑共赴AI时代新程。我整理出这套 AI 大模型突围资料包【允许白嫖】✅从入门到精通的全套视频教程✅AI大模型学习路线图0基础到项目实战仅需90天✅大模型书籍与技术文档PDF✅各大厂大模型面试题目详解✅640套AI大模型报告合集✅大模型入门实战训练这份完整版的大模型 AI 学习和面试资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】①从入门到精通的全套视频教程包含提示词工程、RAG、Agent等技术点② AI大模型学习路线图0基础到项目实战仅需90天全过程AI大模型学习路线③学习电子书籍和技术文档市面上的大模型书籍确实太多了这些是我精选出来的④各大厂大模型面试题目详解⑤640套AI大模型报告合集⑥大模型入门实战训练如果说你是以下人群中的其中一类都可以来智泊AI学习人工智能找到高薪工作一次小小的“投资”换来的是终身受益应届毕业生无工作经验但想要系统学习AI大模型技术期待通过实战项目掌握核心技术。零基础转型非技术背景但关注AI应用场景计划通过低代码工具实现“AI行业”跨界。业务赋能 突破瓶颈传统开发者Java/前端等学习Transformer架构与LangChain框架向AI全栈工程师转型。获取方式有需要的小伙伴可以保存图片到wx扫描二v码免费领取【保证100%免费】