这是一个 SasaDaily 假设商业案例。
一家只有 5 个人的网站维护团队，同时在照顾 4 个不同项目。
一个是自己的公司网站。
两个是客户网站。
另一个是内部使用的小工具。
团队已经开始用 AI Coding Agent 帮忙找 Bug、修改程序与补测试。
但真正让他们头痛的，不是 AI 不会写 Code。
而是每个 Project 的规则都不一样。
客户 A 使用一套部署方式。
客户 B 有不能随便修改的旧系统。
自家公司可以比较快测试。
Production（正式环境）则全部不能由 AI 自己决定上线。
结果工程师每开一个新的 AI Session，都要重新交代一次。
问题不是 AI 不够聪明，而是 Context 每次都要重建
假设这家公司平均每周处理 12 件小型维护工作。
这是 SasaDaily 假设数字。
可能只是：
- 修改一个表单
- 修正手机版排版
- 找出一个错误原因
- 补一个 Test
- 修改 API 串接
- 检查一个部署前问题
以前每开始一件工作，工程师大约要花 12 分钟重新向 AI 说明：
这是哪个 Project。
使用什么技术。
哪些目录可以改。
测试指令是什么。
哪些部分不能碰。
最后能不能部署。
12 分钟是 SasaDaily 假设数字，不是 Qwen Code 官方测量结果。
如果只是偶尔做一次，12 分钟没什么。
但一个月做几十次，就会一直重复。
第一步：把「每次都要讲」的事情变成 Project 规则
Qwen Code 提供 QWEN.md。
它的用途不是替 AI 保存整段聊天，而是放入希望每个 Session 都知道的固定 Instructions（指令）。
例如团队可以写下：
这个 Project 使用哪一套 Build 与 Test 流程。
有哪些 Coding Convention。
哪些 Architecture Decision 不应随便改。
Project Root 的 QWEN.md 可以放团队共用规则。
个人跨 Project 的偏好则可以放在 User 层级。
只有自己在这个 Project 使用的设置，也可以留在 Local 层级。
这样工程师打开不同 Project 时，不必全部从零开始解释。
但这里有一个非常重要的边界：
QWEN.md 是给 AI 的 Instruction，不是 Production 的安全锁。
Qwen Code 官方文档自己也提醒，QWEN.md 越长，遵循可靠度可能下降；如果不同 Instruction 互相冲突，行为也可能不一致。
所以团队不能因为写了一句：
「不要修改 Production。」
就把 Production 权限全部交给 Agent。
第二步：把一件维护工作拆成不同角色
假设今天客户网站突然出现结帐错误。
以前可能是一名工程师自己：
找原因。
改 Code。
跑 Test。
再 Review 自己的修改。
现在可以把工作重新拆开。
这是 SasaDaily 假设工作流。
Agent A：
只负责调查 Root Cause，也就是真正造成问题的原因。
Agent B：
检查现有 Test 是否漏掉这种情况，提出需要补哪些测试。
Agent C：
从 Reviewer 角度检查修改范围、例外情况与可能风险。
Qwen Code 的 Agent 工具可以把多个子任务交给不同 Subagent，并支持平行运行。
另外也有 Agent Team，可以让多个 Teammate 共享任务与交换消息。
但目前 Agent Team 仍属于需要另外激活的实验性功能。
所以小公司不需要一开始就追求「十个 Agent 全自动工作」。
先让 AI 把可以平行的分析工作分开，反而比较实际。
第三步：AI 可以改 Code，不代表 AI 可以决定风险
团队接着创建固定流程：
Instruction → Plan → Modify → Test → Review → Human Approval
先读 Project 规则。
再让 AI 提出 Plan。
确认 Scope 后才修改。
修改完成一定跑 Test。
再看 Diff。
最后才由人决定要不要 Commit、Push 或 Deploy。
Qwen Code 本身也提供不同 Approval Mode。
例如 Plan Mode 可以只分析，不修改文件或运行命令。
Auto-Edit 可以自动处理部分文件修改，但 Shell Command 仍要求批准。
Auto Mode 则会判断部分操作是否安全，高风险操作仍可能被阻止。
更重要的是，真正不能发生的操作，不应只写在 Prompt。
还可以再用 Permission、Sandbox、Workspace Boundary、Git Branch 与人工部署权限限制。
也就是：
Memory 告诉 AI 应该怎么做。
Technical Boundary 决定 AI 实际能做到哪里。
两个不能混为一谈。
第四步：把 Production Approval 留在人手上
假设 Agent 找到 Bug，也完成修改。
Test 全部通过。
Reviewer Agent 也没有发现明显问题。
是不是就直接上线？
不是。
因为客户真正承担的是 Production 结果。
这家公司仍然把四件事留给人：
- 决定这次工作的 Scope
- 决定 Acceptance Criteria，也就是什么才算完成
- 承诺客户什么时候与怎么修改
- 最后批准 Production Deployment
AI 可以替工程师少做很多机械性工作。
但商业责任没有一起转移给 AI。
那到底可能省多少时间？
现在做一个简单的假设。
每周：
12 件小型维护工作。
每月用 4 周计算：
48 件。
以上都是 SasaDaily 假设数字。
原本每件工作重新交代 Project Context、确认指令与环境：
12 分钟。
导入固定 Project Rules 与标准工作流后：
假设降到 4 分钟。
也是 SasaDaily 假设数字。
每件省下：
8 分钟。
48 件 × 8 分钟：
384 分钟。
也就是：
6.4 小时。
如果把内部开发时间假设为每小时 NT$900：
6.4 × NT$900：
等于每月约 NT$5,760 的理论时间价值。
这同样只是 SasaDaily 假设 ROI。
不是 Qwen 官方数据。
也不是保证任何公司导入后都能省下这些钱。
真正结果还要看 Project 复杂度、Agent 使用成本、Review 时间、错误率，以及团队本来的 SOP 有多完整。
小公司真正该看的，不是 Agent 数量
这个案例真正值得注意的，不是：
「现在可以同时开几个 AI Agent？」
而是：
能不能让 AI 接手重复工作，同时让 Project Context、测试、权限与最后责任都没有失控。
如果 AI 每次都要重新教一次。
每个 Project 的规则又混在一起。
Agent 做完后也没有人 Review。
那就算模型再强，团队最后还是要花很多时间收拾。
比较成熟的方式是：
让 Memory 保存应该长期存在的规则。
让 Agent 分担可以独立处理的工作。
让 Test 与 Git 留下可以检查的结果。
让 Permission 限制真正不能碰的地方。
最后把 Production 决定留在人手上。
这时 AI Coding Agent 才不只是「帮忙写 Code」。
而是真正进入一套可以重复使用的工作流程。
今天，和 AI 一起进步一点。
每天学会一个 AI 技巧。
每天节省一点时间。
每天提升一点能力。
SasaDaily，陪你一起成长。
推荐阅读
今日 AI 工具｜2026/08/24：Slack Code，把 AI Coding Agent 拉进 Code Channel，团队一起看计划、改动与 Preview
今日 AI 工具｜2026/08/08：Inspect AI，把 AI Agent 放进可重复测试与沙箱，先看它会怎么失败再上线
