AI 娱乐圈：鹅厂十年开发的AI Agent 探索之路

AI 娱乐圈：鹅厂十年开发的AI Agent 探索之路 AI 娱乐圈：鹅厂十年开发的AI Agent 探索之路 Modified May 31 Code block Plain Text Copy observability dimensions: 1 goal:"当前目标是什么" 2 step:"正在执行哪一步" 3 tool:"用了什么工具" 4 failure:"为什么失败" 5 recovery:"是否触发了重试 / 回退 / 切换" 6 cost:"本轮 token / 时间 / 成本消耗了多少" 如果没有这些视图，系统一复杂，就只能靠猜。猜着猜着就不想维护了。 Eval：4 个持续校准问题 传统软件习惯把评估理解成"上线前测一下"。但 Agent 面对的是开放环境、动态输入、不断变化的上下文。评估必须是持续的： 对 Agent 来说， 评估不是验收动作，而是日常运行信号。 Control Plane：权限、边界、审计 当系统接了更多工具、更多角色、更多目标，问题就不再是"能不能跑"，而是： • 谁可以调用哪些工具？ • 哪些动作默认允许，哪些必须人工确认？ • 哪些路径只能读，哪些能写？ • 哪些任务失败后必须停下来？ 从 demo 到系统，中间隔着的不是更多 Prompt，而是 control plane。 脚手架 模型 这是我所有原则里最反常识的一条。 24h 打工人用的不是最贵的模型。codex 配额用完切 gemini，gemini 挂了切 claude——都不是顶配。但有 SDD 流程 + 调度层 + 失败切换 + constitution.md，效果远好于直接用一次性的顶级模型。 Code block Plain Text Copy 投入回报对比（个人经验估算）： 模型升级：成本 +300%，效果 +20% 脚手架升级：成本 +50%，效果 +200% → 优先投资脚手架，而不是追最新最贵的模型 一个设计精良的系统让弱模型发挥惊人性能。反过来，烂系统完全浪费掉顶级模型的能力。 Agent 系统的 5 层地基 如果今天让我重新概括 Agent 系统的地基，至少有五层： 1. 目标表达： 2. 到底想完成什么 3. 能力单元： 4. 有哪些 Skill / 工具 / 工作流 5. 运行时状态： 6. 当前正在做什么 7. 治理边界： 8. 允许做什么，不允许做什么 9. 评估反馈： 10. 哪些行为值得固化，哪些必须修正 少任何一层，系统都可能看起来能跑，但跑不稳。 垃圾的思考乘以强大的模型，等于精美的垃圾。 工程建议： 如果你的系统还没有 observability（至少能回答"它为什么失败"），那比换一个更强的模型优先级高 10 倍。先投治理，再投模型。 你觉得"脚手架 模型"对吗？有没有反例？ ··· 第七章：协议层正在成形 做到这里，我的视角发生了第二次升级。 以前关心的是：怎么把一个 Agent 系统搭起来。现在更关心的是： 整个行业在形成哪些共识性的基础设施？ 如果只盯着单个 Agent，很容易把问题看成"Prompt + 工具 + 工作流"。但从 2025 年开始，一个更大的变化出现了：Agent 正在从单系统里的自动化，走向跨系统互操作。 时间 事件 意义 2025 03 11 OpenAI 发布 Agents 新基座 Responses API + Tools + SDK + Tracing，runtime 开始收敛 2025 04 09 Google 发布 A2A Agent 间协作有了协议化趋势 2025 06 23 A2A 捐给 Linux Foundation 从企业项目变行业标准 2026 02 13 GitHub 发布 Agentic Workflows 技术预览 Agent 进入 CI / PR / Issue 主流程 2026 03 16 Microsoft Foundry Agent Service GA Responses API runtime + 全链路 tracing + 企业级 eval 2026 04 07 GitHub Dependabot → AI agent remediation 安全告警自动修复成为现实 Responses API：runtime 在收敛 OpenAI 把 Responses API、内置 Tools、Agents SDK、Tracing 组合成了更明确的开发路径。Assistants API 后续将逐步让位。 这件事的重要性在于：Agent 开发正在从"自己拼一堆能力"，走向"围绕统一 runtime 和工具语义来构建"。 MCP：工具接入标准化 我自己过去解决的是"怎么让 Agent 调 CLI、读文件、改代码"。MCP 解决的是更通用的问题：Agent 怎么以标准方式接入工具、资源和外部系统。 Code block Plain Text Copy { "tool":"code search", "description":"Search codebase by semantic query", "input schema":{ "type":"object", "properties":{ "query":{"type":"string"}, "scope":{"enum":["current repo","org repos"]}, "max results":{"type":"integer","default":10} } }, "permissions":["read:code"], "rate limit":"100/min" } 一旦工具接入开始标准化，重点就从"每家自己造一套胶水层"转向"怎样设计更稳定的资源暴露、权限边界和调用语义"。 A2A：多 Agent 怎么协作 Agent 的下一个问题，不是单点更聪明，而是多 Agent 怎么协作、发现、协商和同步状态。 这和我自己踩过的坑是同一类问题：主 Agent 上下文越来越重；子 Agent 返回后如何续跑；多角色如何共享状态而不是靠人手工搬运上下文。以前只能各自造轮子，现在开始出现协议化趋势了。 我的判断 Agent 开发正在从"框架之争"，转向"协议 + runtime + control plane 之争"。 这不代表框架不重要，而是它们正在往更底层、更标准化的方向收敛。对个人开发者来说，现在值得花时间理解的不是某个框架的 API，而是这些协议背后的设计理念。 未来做 Agent，越来越像搭操作系统，不只是写 prompt。 工程建议： 选技术栈时，优先看它是否兼容 MCP / Responses API 这些正在收敛的协议。自己造的胶水层越多，未来迁移成本越高。协议层是长期资产，框架是短期工具。 你在用 MCP 了吗？体验怎么样？ ··· 第八章：从 Task Driven 到 Goal Driven 前面讲的所有实践，回头看，本质上都是 Task Driven： 我先把值得做的事想好，送进系统，系统负责拆解、执行、留痕。 这套模式非常有效。但它有一个我撞了很久才意识到的边界： 24h 在线，不等于 24h 迭代。 系统虽然能 24 小时执行，但这些更高层的判断仍然依赖我： • 现在最值得做什么？ • 哪个方向应该继续推进？ • 遇到阻塞时该换路径还是等待？ • 哪些问题值得主动探索？ 系统在干活，但活还是我在派。 只要任务还需要我持续供给，我就仍然是系统的瓶颈。 这才是问题的根。 Task Driven vs Goal Driven 从 Task Driven 到 Goal Driven 维度 Task Driven Goal Driven 人的角色 项目经理 + 执行监督 目标设定者 / 审核者 Agent 的角色 执行器 自主推进者 决策中心 在人脑子里 在目标 + 边界 + 系统状态里 主要成本 人持续编排 前期建模和约束设计 适用场景 简单、一次性任务 长期、复杂、持续推进任务 简单说： Task Driven 解决执行问题，Goal Driven 解决迭代问题。 前者让系统开始能跑，后者才让系统开始能持续向前。 Goal Driven 的 5 个前提 很多人不敢放手让 Agent 自主推进，担心它跑偏、浪费 token、做无效工作。这些担心都成立。 所以 Goal Driven 对系统提出了更高要求： 1. 目标必须清晰 2. —— 不是模糊愿望，而是可推进、可判断的目标表达。 3. 边界必须清晰 4. —— 哪些能做，哪些不能做，资源上限是什么。 5. 状态必须可见 6. —— 当前做到哪一步，卡在哪，为什么卡。 7. 过程必须留痕 8. —— 否则你无法知道它为什么成功，也无法知道它为什么失败。 9. 权限必须可控 10. —— 它到底能调用哪些工具，能写到哪里，谁来兜底。 只有在这 5 个前提成立时，自主推进才是资产；否则只会把错误放大得更快。 Goal Driven 不是更放权，而是更强约束下的有限自治。 共享状态：STATE.yaml Goal Driven 一旦进入多步骤、多角色协作，主 Agent 本身会变成新的瓶颈——上下文越来越重、通信越来越慢、单点故障。 更务实的做法是用共享状态来协调： Code block Plain Text Copy STATE.yaml — 共享任务面板 goal:"优化搜索模块响应速度，P95 从 800ms 降到 200ms" owner:"joefu" deadline:"2026 05 01" constraints: "不修改已有 API 契约" "每日 API 成本不超过 $5" "所有架构变更需记录在 changelog.md" agents: profiler: status:"completed" output:"analysis/search perf baseline.json" summary:"瓶颈定位在 DB 全表扫描和缺少缓存层" backend dev: status:"in progress" current step:"为热点查询添加 Redis 缓存" blocked:false test runner: status:"pending" depends on: ["backend dev"] description:"回归测试 + 性能压测验证" next review:"2026 04 15" 如果没有这些视图，系统一复杂，就只能靠猜。猜着猜着就不想维护了。 Eval：4 个持续校准问题 传统软件习惯把评估理解成"上线前测一下"。但 Agent 面对的是开放环境、动态输入、不断变化的上下文。评估必须是持续的： 对 Agent 来说， 评估不是验收动作，而是日常运行信号。 Control Plane：权限、边界、审计 当系统接了更多工具、更多角色、更多目标，问题就不再是"能不能跑"，而是： • 谁可以调用哪些工具？ • 哪些动作默认允许，哪些必须人工确认？ • 哪些路径只能读，哪些能写？ • 哪些任务失败后必须停下来？ 从 demo 到系统，中间隔着的不是更多 Prompt，而是 control plane。 脚手架 模型 这是我所有原则里最反常识的一条。 24h 打工人用的不是最贵的模型。codex 配额用完切 gemini，gemini 挂了切 claude——都不是顶配。但有 SDD 流程 + 调度层 + 失败切换 + constitution.md，效果远好于直接用一次性的顶级模型。 一个设计精良的系统让弱模型发挥惊人性能。反过来，烂系统完全浪费掉顶级模型的能力。 Agent 系统的 5 层地基 如果今天让我重新概括 Agent 系统的地基，至少有五层： 1. 目标表达： 2. 到底想完成什么 3. 能力单元： 4. 有哪些 Skill / 工具 / 工作流 5. 运行时状态： 6. 当前正在做什么 7. 治理边界： 8. 允许做什么，不允许做什么 9. 评估反馈： 10. 哪些行为值得固化，哪些必须修正 少任何一层，系统都可能看起来能跑，但跑不稳。 垃圾的思考乘以强大的模型，等于精美的垃圾。 工程建议： 如果你的系统还没有 observability（至少能回答"它为什么失败"），那比换一个更强的模型优先级高 10 倍。先投治理，再投模型。 你觉得"脚手架 模型"对吗？有没有反例？ ··· 第七章：协议层正在成形 做到这里，我的视角发生了第二次升级。 以前关心的是：怎么把一个 Agent 系统搭起来。现在更关心的是： 整个行业在形成哪些共识性的基础设施？ 如果只盯着单个 Agent，很容易把问题看成"Prompt + 工具 + 工作流"。但从 2025 年开始，一个更大的变化出现了：Agent 正在从单系统里的自动化，走向跨系统互操作。 时间 事件 意义 2025 03 11 OpenAI 发布 Agents 新基座 Responses API + Tools + SDK + Tracing，runtime 开始收敛 2025 04 09 Google 发布 A2A Agent 间协作有了协议化趋势 2025 06 23 A2A 捐给 Linux Foundation 从企业项目变行业标准 2026 02 13 GitHub 发布 Agentic Workflows 技术预览 Agent 进入 CI / PR / Issue 主流程 2026 03 16 Microsoft Foundry Agent Service GA Responses API runtime + 全链路 tracing + 企业级 eval 2026 04 07 GitHub Dependabot → AI agent remediation 安全告警自动修复成为现实 时间 时间 事件 事件 意义 意义 2025 03 11 2025 03 11 OpenAI 发布 Agents 新基座 OpenAI 发布 Agents 新基座 Responses API + Tools + SDK + Tracing，runtime 开始收敛 Responses API + Tools + SDK + Tracing，runtime 开始收敛 2025 04 09 2025 04 09 Google 发布 A2A Google 发布 A2A Agent 间协作有了协议化趋势 Agent 间协作有了协议化趋势 2025 06 23 2025 06 23 A2A 捐给 Linux Foundation A2A 捐给 Linux Foundation 从企业项目变行业标准 从企业项目变行业标准 2026 02 13 2026 02 13 GitHub 发布 Agentic Workflows 技术预览 GitHub 发布 Agentic Workflows 技术预览 Agent 进入 CI / PR / Issue 主流程 Agent 进入 CI / PR / Issue 主流程 2026 03 16 2026 03 16 Microsoft Foundry Agent Service GA Microsoft Foundry Agent Service GA Responses API runtime + 全链路 tracing + 企业级 eval Responses API runtime + 全链路 tracing + 企业级 eval 2026 04 07 2026 04 07 GitHub Dependabot → AI agent remediation GitHub Dependabot → AI agent remediation 安全告警自动修复成为现实 安全告警自动修复成为现实 Responses API：runtime 在收敛 OpenAI 把 Responses API、内置 Tools、Agents SDK、Tracing 组合成了更明确的开发路径。Assistants API 后续将逐步让位。 这件事的重要性在于：Agent 开发正在从"自己拼一堆能力"，走向"围绕统一 runtime 和工具语义来构建"。 MCP：工具接入标准化 我自己过去解决的是"怎么让 Agent 调 CLI、读文件、改代码"。MCP 解决的是更通用的问题：Agent 怎么以标准方式接入工具、资源和外部系统。 一旦工具接入开始标准化，重点就从"每家自己造一套胶水层"转向"怎样设计更稳定的资源暴露、权限边界和调用语义"。 A2A：多 Agent 怎么协作 Agent 的下一个问题，不是单点更聪明，而是多 Agent 怎么协作、发现、协商和同步状态。 这和我自己踩过的坑是同一类问题：主 Agent 上下文越来越重；子 Agent 返回后如何续跑；多角色如何共享状态而不是靠人手工搬运上下文。以前只能各自造轮子，现在开始出现协议化趋势了。 我的判断 Agent 开发正在从"框架之争"，转向"协议 + runtime + control plane 之争"。 这不代表框架不重要，而是它们正在往更底层、更标准化的方向收敛。对个人开发者来说，现在值得花时间理解的不是某个框架的 API，而是这些协议背后的设计理念。 未来做 Agent，越来越像搭操作系统，不只是写 prompt。 工程建议： 选技术栈时，优先看它是否兼容 MCP / Responses API 这些正在收敛的协议。自己造的胶水层越多，未来迁移成本越高。协议层是长期资产，框架是短期工具。 你在用 MCP 了吗？体验怎么样？ ··· 第八章：从 Task Driven 到 Goal Driven 前面讲的所有实践，回头看，本质上都是 Task Driven： 我先把值得做的事想好，送进系统，系统负责拆解、执行、留痕。 这套模式非常有效。但它有一个我撞了很久才意识到的边界： 24h 在线，不等于 24h 迭代。 系统虽然能 24 小时执行，但这些更高层的判断仍然依赖我： • 现在最值得做什么？ • 哪个方向应该继续推进？ • 遇到阻塞时该换路径还是等待？ • 哪些问题值得主动探索？ 系统在干活，但活还是我在派。 只要任务还需要我持续供给，我就仍然是系统的瓶颈。 这才是问题的根。 Task Driven vs Goal Driven 从 Task Driven 到 Goal Driven 维度 Task Driven Goal Driven 人的角色 项目经理 + 执行监督 目标设定者 / 审核者 Agent 的角色 执行器 自主推进者 决策中心 在人脑子里 在目标 + 边界 + 系统状态里 主要成本 人持续编排 前期建模和约束设计 适用场景 简单、一次性任务 长期、复杂、持续推进任务 维度 维度 Task Driven Task Driven Goal Driven Goal Driven 人的角色 人的角色 项目经理 + 执行监督 项目经理 + 执行监督 目标设定者 / 审核者 目标设定者 / 审核者 Agent 的角色 Agent 的角色 执行器 执行器 自主推进者 自主推进者 决策中心 决策中心 在人脑子里 在人脑子里 在目标 + 边界 + 系统状态里 在目标 + 边界 + 系统状态里 主要成本 主要成本 人持续编排 人持续编排 前期建模和约束设计 前期建模和约束设计 适用场景 适用场景 简单、一次性任务 简单、一次性任务 长期、复杂、持续推进任务 长期、复杂、持续推进任务 简单说： Task Driven 解决执行问题，Goal Driven 解决迭代问题。 前者让系统开始能跑，后者才让系统开始能持续向前。 Goal Driven 的 5 个前提 很多人不敢放手让 Agent 自主推进，担心它跑偏、浪费 token、做无效工作。这些担心都成立。 所以 Goal Driven 对系统提出了更高要求： 1. 目标必须清晰 2. —— 不是模糊愿望，而是可推进、可判断的目标表达。 3. 边界必须清晰 4. —— 哪些能做，哪些不能做，资源上限是什么。 5. 状态必须可见 6. —— 当前做到哪一步，卡在哪，为什么卡。 7. 过程必须留痕 8. —— 否则你无法知道它为什么成功，也无法知道它为什么失败。 9. 权限必须可控 10. —— 它到底能调用哪些工具，能写到哪里，谁来兜底。 只有在这 5 个前提成立时，自主推进才是资产；否则只会把错误放大得更快。 Goal Driven 不是更放权，而是更强约束下的有限自治。 共享状态：STATE.yaml Goal Driven 一旦进入多步骤、多角色协作，主 Agent 本身会变成新的瓶颈——上下文越来越重、通信越来越慢、单点故障。 更务实的做法是用共享状态来协调： 每个 Agent 自己读取状态、写回进度，主会话只负责高层目标和验收。主会话负责方向，不负责搬运；系统负责推进，不靠人反复传话。 6 步落地路径 如果你也想开始做 Agent，我建议这个顺序： 步骤 做什么 核心产出 第一步 写清楚 spec 要做什么、不做什么、怎么算完成 第二步 执行过程留痕 Prompt / 状态 / 输出 / 错误全记录 第三步 补 observability 和 eval 知道为什么成功、为什么失败 第四步 高频动作沉淀为 Skill 模板 + 规则 + 代码 第五步 引入调度和并发 调度层 + 轮询 + 失败切换 第六步 最后才尝试 Goal Driven 目标表达 + 治理边界 + 共享状态 步骤 步骤 做什么 做什么 核心产出 核心产出 第一步 第一步 写清楚 spec 写清楚 spec 要做什么、不做什么、怎么算完成 要做什么、不做什么、怎么算完成 第二步 第二步 执行过程留痕 执行过程留痕 Prompt / 状态 / 输出 / 错误全记录 Prompt / 状态 / 输出 / 错误全记录 第三步 第三步 补 observability 和 eval 补 observability 和 eval 知道为什么成功、为什么失败 知道为什么成功、为什么失败 第四步 第四步 高频动作沉淀为 Skill 高频动作沉淀为 Skill 模板 + 规则 + 代码 模板 + 规则 + 代码 第五步 第五步 引入调度和并发 引入调度和并发 调度层 + 轮询 + 失败切换 调度层 + 轮询 + 失败切换 第六步 第六步 最后才尝试 Goal Driven 最后才尝试 Goal Driven 目标表达 + 治理边界 + 共享状态 目标表达 + 治理边界 + 共享状态 先让一次执行可复盘，再让它可重复，再让它可规模化，最后让它可有限自主。 工程建议： Goal Driven 必须建立在成熟的 Task Driven 基础上。一个连任务都执行不稳定、没有留痕、没有 Skill 沉淀的系统，不可能真的进入目标驱动。别跳步。 你的 Agent 系统现在在哪一步？卡在哪里？ ··· 结语：增强自我，而非取代自我 回到开头的问题：人是瓶颈。 但一年走下来，我对这句话的理解变了。 瓶颈不是人的能力不够，而是人的注意力有限。4 6 个终端是上限，不是因为不够努力，而是人脑的并发模型就长这样。解决方案不是"让 AI 替代人"，而是"让系统不再依赖人的实时在场"。 24h 打工人的 SDD 是这个系统的地基： • spec.md • 把模糊的需求变成明确的目标 • plan.md • 把目标变成技术方案 • tasks.md • 把方案变成可执行的步骤 • constitution.md • 把经验变成可复用的约束 • eval / trace / policy • 把系统变成可观测、可治理、可持续迭代的能力体 Goal Driven 是它的下一站：让系统不只是等你派活，而是围绕目标自主向前走。 回顾整条路——从 4 个终端的手忙脚乱，到 Vibe Coding 翻车后的痛定思痛，到 24 小时无人值守的稳定执行，到 Agent 自己修自己的 bug，再到协议层正在收敛的行业共识——每一步的认知转折都不是提前设计好的，是被实践逼出来的。 真正的跃迁，不是让 AI 多做几个步骤，而是让人退出微观调度。 增强自我，而非取代自我。共勉。 🔗 原文链接： https://mp.weixin.qq.com/s/ThmL1okJ... https://mp.weixin.qq.com/s/ThmL1okJ... 原创 慢慢精通 慢慢精通 随机比特2026年4月14日 07:43 广东 曾经前端被戏称为"娱乐圈"——工具、框架层出不穷，今年🔥的明年就过时。现在 AI 把这个周期压缩到了以月计：这个月的新概念，下个月可能就是旧闻。这篇文章，就是一个在"AI 娱乐圈"摸爬滚打的老开发，试图从月抛式的焦虑中找到不会过期的东西。 本文约 10000 字，阅读约 25 分钟。建议收藏后分章节阅读。 • 4 6 个终端的并发上限，怎么突破 • 80% 的 AI 需求，10 行 Bash 就够了 • Vibe Coding 翻车全记录 • 24h 无人值守的代码开发 Agent 怎么造 • 从 Task Driven 到 Goal Driven 的认知跃迁 ··· 目录 1. 起点：人是瓶颈 2. 80% 的 AI 需求不需要 AI 3. Vibe Coding 翻车记 4. 24h 打工人——第一个真正的系统 5. Agent 自己修了自己的 bug 6. 从 demo 到系统——门槛不是模型，是治理 7. 协议层正在成形 8. 从 Task Driven 到 Goal Driven ··· 第一章：起点——人是瓶颈 此刻我的屏幕上开着 5 个终端。 左上角，codex 正在跑一组单元测试，终端里绿色的 pass 和偶尔的红色 fail 交替滚动。右上角，gemini cli 在按照我刚给的方案改一个接口的入参校验。左下角，claude 在根据最新的 API 变更生成文档。右边整块屏幕留给了 Cursor，里面同时开着两个 Agent 窗口——一个在重构组件，一个在补集成测试。 看起来很酷？ 真实体验是这样的：codex 那个终端跑了五分钟没动静，我得翻上去看是卡住了还是在等确认；gemini 改完接口了，但我忘了它改的是哪个分支；claude 写的文档引用了一个旧接口名，因为我忘了告诉它刚才 gemini 改过了；Cursor 里的重构窗口弹了个确认框，我一直没注意到，白白等了十分钟。 这种模式的上限大概就是 4 6 个并发。再多，人脑的 context switch 就开始崩溃。 人工并发有三个硬伤： 限制 具体表现 后果 吞吐有限 一天能管 4 6 个 Agent 窗口 任务量有硬上限 状态不稳定 上下文丢失、判断漂移、质量波动 上午管 5 个，下午犯困管不了 3 个 难以规模化 做成一次不难，稳定重复难 今天的成功经验明天就忘了 限制 限制 具体表现 具体表现 后果 后果 吞吐有限 吞吐有限 一天能管 4 6 个 Agent 窗口 一天能管 4 6 个 Agent 窗口 任务量有硬上限 任务量有硬上限 状态不稳定 状态不稳定 上下文丢失、判断漂移、质量波动 上下文丢失、判断漂移、质量波动 上午管 5 个，下午犯困管不了 3 个 上午管 5 个，下午犯困管不了 3 个 难以规模化 难以规模化 做成一次不难，稳定重复难 做成一次不难，稳定重复难 今天的成功经验明天就忘了 今天的成功经验明天就忘了 所以真正的命题不是"怎么让 AI 更聪明"。Agent 的价值不是替人做事，是把依赖人的高频工作，改造成可以持续执行、可观测、可复盘、可优化的系统。 人是瓶颈。但解决瓶颈的方式不是让 AI 替代人，而是让系统不再依赖人的实时在场。 想明白这件事之后，我开始动手。但在造系统之前，我先学到了一条最重要的原则。 工程建议： 如果你现在也在手动管多个 AI 终端，先别急着造系统。先记录一周：哪些操作是重复的？哪些切换是可以消除的？瓶颈清单比技术方案更重要。 你现在同时开几个 AI 窗口？上限是多少？评论区聊聊。 ··· 第二章：80% 的 AI 需求不需要 AI 我开始认真折腾 AI 的时候，第一件事不是去调模型、搞 RAG，而是写了一套 Bash 脚本来自动化日常工作流。 结果发现—— 80% 的"AI 需求"，根本不需要 AI。 自动拉取代码跑测试？Bash。定时检查服务健康状态？ cron + curl。 把 JSON 日志格式化成报表？ jq + awk。 文件变更触发构建？ inotifywait + shell。 这些东西不需要任何模型，10 行脚本就搞定了。 这让我提炼出后来最重要的一条原则： 代码优先于 Prompt。能用 10 行 Bash 解决的，别折腾 AI。 听起来像