作者继八月 AI Native 实践后，记录从 Stage 7 迈向 Stage 8 的多 Agent 工作方式探索。核心实践包括：用「测试测试」验证测试有效性（借鉴变异测试）；要求 Agent 交代判断依据；采用 1+N 组织方式，由 Captain 统筹调度其他 Agent，并保护其上下文不陷入实现细节；用 logbook Kit（lbkit）串起需求到上线的完整交付流程，通过 Preflight 预演减少中途打断；让 Delivery 与 Verify 两种角色形成对抗，发现分歧。作者强调多 Agent 有成本需按任务规模挑选，目标是保护人的完整注意力与决策密度，认为对抗机制比单纯循环更重要。
作者分享了作为 Infra/Kubernetes 工程师在 AI Native 时代的工作方式演变：从 2 月认为 Code Typing 不必要，到 5 月确立「AI 放大执行、人负责判断」，再到 8 月形成信息、研发、落地、工具链的完整链路。信息层面，他用 minds（AI 参与度 90%+）和 my-kms（5%）两个知识仓库，Agent 改动走 PR 流程由人 review；编码层面推行 Spec-driven、用 guides 固化约束、自测 Agent 分层验证；工具链上自建 mind-forge、skm 等工具。核心观点：AI 善于「作」（生产、展开、润色），人负责「创」（问题、判断、观点），工作重点是决策密度、共识形成与保留个人棱角。
作者以前端资源缩减为契机，从后端工程师视角亲自承担前端项目，总结了高密度页面的信息组织指南。文章指出 CRUD 页面只解决数据增删改查，却不回答用户先看什么、依据什么做决定。作者提出组织信息架构的三个核心问题：用户最该看到什么、需要哪些关联信息、完成后要做什么。并以 GitHub Projects、Notion 为例，对比表格、看板、日历等'表达骨架'的适用场景，给出卡片网格、看板、日历排期、仪表盘、层级树、状态墙等 19 种信息呈现方式的参考表。指南还可直接交给 Agent 用于检查和改造前端页面，让 AI 辅助但由人把握业务判断。
