16 张任务卡、3.2 亿 token、18 小时:我的 Kimi Code 数字员工团队第一战(S3)
我,39 岁,高速公路施工单位上班,业余在用 AI 造一支"数字员工团队"。前天深夜我下了一道命令:把我那个老旧的技术博客推倒,基于 ThinkPHP 的 BuildAdmin 框架二开重建,按 GEO(面向 AI 搜索的内容工程)标准重做。
18 小时后,https://www.wdmeng.cn 切换上线。
干这活的不是我自己通宵——是四个"数字员工":一个调度总岗(CIO)、一个产品设计岗、一个后端岗、一个测试岗,全部跑在 Kimi Code 上,全程无头模式(命令行非交互,没有人盯屏)。这篇文章报战绩,也把"满血数字员工团队怎么搭"这件事写清楚——它简单得超出想象。
先说战绩:这一仗交付了什么
不是"弄几个页面上传到 VPS"。这是一套完整系统的二开:需求文档、PRD、架构、页面设计、前后端开发、数据库、测试、运维上线,全链路(git 提交时间戳实证:09-15 06:43 首个阶段提交 → 17:40 切换上线;立项在 9-14 深夜,全程约 18 小时)。
工程侧(全部实测数字,出自各卡交付报告):
- 需求与 PRD:597 行定稿 PRD,40 条可实跑的验收标准(AC),7 条回归基线;
- 前台:9 屏设计落地,8 条路由、7 个控制器、10 个模板;36.5KB 手写 CSS + 7 项 JS 渐进增强;GEO 五件套(页级 TDK、canonical、JSON-LD、sitemap、robots)源码层直出;
- 后台:文章/板块管理改造,4 个 Vue 页面;后台 API 实测 62/62、条目生成器 60/60 全过;
- 数据库:20 个迁移脚本,裸库一条命令建到最新(中间被抓出"迁移链不自足"打回重修过);新库独立账号,密码全程 600 权限文件;
- 安全与运维:composer 5 个依赖升级、漏洞告警清零;npm 21 高危 2 严重清零;服务器备份 cron(每日 mysqldump+文件打包,留 7 天,恢复演练实测过);nginx vhost、SSL 证书、www 域名切换带 30 秒回滚预案。
内容侧(上线即饱满,不是空壳站):
- 我的 IPMS 内容系统里 39 篇已发布成稿,连封面带摘要迁进 5 个子分类;
- 笔记素材池 172 篇进"AI 工作日志"——隐私过滤器自动拦截了 68 条(个人档案、财务计划、每日清单这类私货,一条没上去);
- 研报 10 篇进"调研报告"板块;AI 资讯爬虫抓 30 天日报,服务器 cron 每天自动增量;
- 50 个媒体文件本地化,全站封面图兜底。
质量过程:全量验收 40 条 AC 首验 34 过、3 打回、3 项浏览器阻塞——打回项全部修复复验闭环;正式上线前测试岗用 32 张三视口截图逐张目检,又抓出一个平板端破版,修完才放行。
成本:3.2 亿 token 是什么概念
两阶段合计约 3.2 亿 token(自报口径:按 Kimi Code wire 日志四字段全量统计,含缓存读取;其中 9 月 15 日凌晨第一阶段就烧了约 2.7 亿,当周额度 20% 一次打穿,我早上看到账单时血压都高了)。
数字吓人,但拆开看结构:非缓存的真实新算量只占零头,97% 是缓存读——无头长会话每一轮都要把全量上下文重新发一遍,这是滚雪球的主因。这一仗烧出来的教训直接改了我的团队章程:成本汇报必须四字段全列,派大单前先报预算,获批再派。
重点:满血数字员工团队,到底怎么搭的
这是我最想写清楚的部分。很多人觉得"多智能体团队"要上 CrewAI 这类编排框架——我自己就是花了两个月把 58k star 的 CrewAI 开发线推翻的人(那是上一个故事)。现在的答案简单得多:Kimi Code 无头模式 + 文件夹即岗位。
一个岗位 = 一个文件夹,三件套:
01_产品设计岗/
├── agent.md # 岗位身份章程(我是谁、职责、纪律)
├── skills/ # 这个岗挂的技能包(产品岗挂了 28 技能链式套件)
└── .kimi-code/mcp.json # 这个岗的 MCP 工具(数据库、文档库等,自动加载)
每个文件夹就是一个独立项目。岗位实例启动命令长这样:
cd 01_产品设计岗 && kimi --agent-file agent.md \
--skills-dir "D:\code\dev\01_产品设计岗\skills" \
-m kimi-code/k3-256k -p "<任务指令>"
--agent-file 注入岗位身份,--skills-dir 挂技能(注意:必须绝对路径,相对路径会静默不加载任何技能——这是踩过的坑),MCP 自动读岗位目录下的配置。岗位最小权限:产品岗碰不到数据库,后端岗碰不到浏览器,各岗只能用自己的工具。
两种用法都成立:
- 单独跑:你想让一个岗干活,进它的文件夹,一条命令拉起,它就是一个满血智能体(身份+技能+工具全挂载);
- 统一调度:调度总岗(CIO,也就是"军师")通过工作流 + 任务卡派单——每张卡写死任务、涉及文件清单(任何两张卡写入范围零交集,文件互斥铁律)、可实跑的验收标准;岗位干完必须带 diff 自证 + 新鲜实跑证据交付,验收不过就打回。
甚至,从 HTML 网页端就能拉起一个满血 agent:我的 IPMS 内容系统里,"写母稿""组包"按钮点下去,后端 FastAPI 起一个子进程跑 Kimi Code 无头实例,产线开始干活,页面轮询进度——网页只是遥控器,真正干活的是终端里那个满血智能体。这次博客重建的派单,本质上也是同一个模式。
这一仗的真实曲折(不全是捷报)
成功是整体的,过程是摔打的,挑四个最值得说的:
- 凌晨烧穿额度:第一阶段 2.7 亿 token 里 97% 是缓存读滚雪球。教训沉淀成规则:大任务拆子代理、单卡控制 turn 数,就是控成本。
- 并行破窗:两个岗同时干活时,一个
npm run build把 public/ 目录整个清空(vite 的 emptyOutDir 默认行为),另一个岗的产出被冲掉。从此并行卡禁整树 git 命令,构建副作用必须事前声明。 - 隐私漏网:内容迁移时隐私过滤器只认 P0 标记,16 篇我的私人每日清单溜进了公开博客——是调度岗抽验时用反向探针(库里搜禁词)抓获的,全部下架。验收不能只查"该在的在不在",还要查"不该在的在不在"。
- 智能体也会挂死:迁移卡的实例 LLM 请求挂死 24 分钟零响应,看门狗熔断、会话续跑接着干,上下文不丢。
还有一个虚惊:我第一次打开新站时差点骂人——项目卡全指向同一篇文章、列表页挤成窄条、站名还是旧的。查下来是 join 查询字段覆盖、CSS 网格预留列塌陷、种子数据没换名三个独立 bug。而之前验收报告写的是"40 条 AC 全绿"。curl grep 验得出"卡片存在",验不出"链接错了"和"排版烂了"——从此前台验收硬性带浏览器截图目检。
可抄走的清单
如果你也想搭自己的数字员工团队,这是这一仗验证过的最小配置:
- 岗位 = 文件夹:
agent.md(身份)+skills/(技能)+.kimi-code/mcp.json(工具); - 调度 = 任务卡:一卡一事、写入范围显式声明、验收标准必须可实跑;
- 交付铁律:diff 自证 + 新鲜证据(退出码/截图),无证据禁宣称完成;
- 互斥铁律:任何两个执行体不得同时写同一文件;
- 熔断线:同一任务两次打回先归因再决策;编码岗 30 万 token 零写入主动熔断;
- 成本纪律:token 统计全口径(含缓存读),派大单前报预算;
- 验收新规:结构性断言(curl)+ 视觉目检(截图)双通道,缺一不可。
最后
18 小时,16 张任务卡,一个可以对外见人的网站,外加一整套被实战打磨过的调度纪律。我宣布这一战成功——虽然内容深度、封面图精细度都还有优化空间,但"文件夹即岗位、任务卡即军令、证据即交付"这套打法,跑通了。
数字员工团队不是概念,是文件夹。
素材点:3.2 亿 token 成本结构(97% 缓存读)/ CrewAI 开发线推翻始末(前文)/ IPMS 网页端拉起无头智能体的实现/ 隐私过滤器双探针设计/ 任务卡模板全文
