
作者回复: 非常感谢你把问题提到这个层次 这种问题,正是我最希望在课程讨论区看到的。这就是这门课想要引导大家去思考的“工程级问题”。 你提到的这个真实场景非常典型:因为AI对整条调用链、对端体验缺乏全局认知,因此导致线上 7s 无响应的问题。 那么问题的本质就不是 “AI写错了代码”,而是,AI “没有” 被赋予在设计阶段主动审视影响面的职责和上下文!——这是问题的本质。 因此,如你所说,我们的思考可以是: 是否需要在方案阶段,引入一个专门负责影响面分析和链路回溯的 Sub-Agent? 是否需要用 Skill,把存量系统的链路知识、关键 SLA、用户侧体验约束沉淀成 AI 可查询、可复用的结构化知识? 然后在什么场景调用Skills 或如何把相关Skills赋予相关的Sub-Agent? 我的愿景的确是希望大家学习之后,能够实现:当遇到这种问题时,应该如何把“工程经验”翻译成 AI 的职责边界、能力划分和调用结构?—— 要做到这一点,也需要首先学习原理,如何配置,同时引入更多的工程场景实践。 后续课程能否达到这个期待标准 —— (这是一个非常高的要求)—— 我不敢打百分之百的包票,但是我会尽自己最大的能力往这个方向去设计。 一起加油!
作者回复: ❤️

作者回复: 🚵♀️🚣🧗♀️

作者回复: 学起来
作者回复: 反了。应该是把Skills(能力)配置到 SubAgent 去。 在交互对话Log中,Claude Code命令行会明确写出它正在调用哪个SubAgent。
作者回复: 哇。我会觉得这个建议超好耶!!让我和我的编辑老师商量一下。真希望能够邀请到和尚同学共创!

作者回复: 还是接着上面的讨论哈。我们学习的目标并不是教大家再造一个比现有插件更强的 review 工具;而是当现成工具的 review 结论不够用时,我们在进行现状分析之后,可以清楚地知道:是缺了哪类上下文?是该加一个专注影响面分析的 Agent?还是该把链路、SLA、用户侧约束沉淀成 Skill,让 AI 在 review 阶段就“看得到”?—— 这些思考只能够来源于工程实践,对吧?而且也只有在具体项目的分析中才能够动态的进行选择。 举一个我自己做项目时候的例子哈——训练大模型,开始就是一遍一遍的反复训练,然后CC帮我做日志分析,观察W&B,当日志越来越多,项目结构越来越乱。此时我才开始思考——是不是此时该来一个负责日志分析的SubAgent了。这些都是很动态的决定,但是前提是我需要先知道子代理的优缺点和来龙去脉。 期待后续章节中更多类似的深入讨论。。。