@moximoxi #37 测试的作用是什么？ai了，为何测试做的，ai不能做呢？打破传统流程和思维，平权
leo.kuang
用户 ID 13133 · 当前名首次快照 2026-08-12 10:16:18 · 当前名始于 2026-08-12 10:16:18 · 原站主页: https://linux.sb/user/13133
发言
共 8 楼
核心问题：为什么好心行动常造成坏结果？
↓
基础透镜：系统 = 要素 + 连接 + 目标
↓
动态语言：存量 + 流量 + 反馈回路
↓
两类回路：调节回路维持平衡；增强回路放大趋势
↓
典型行为：增长、衰退、稳定、振荡、崩溃
↓
系统之美：适应力 + 自组织 + 层次性
↓
系统之奇：表象 + 非线性 + 边界 + 限制因素 + 延迟 + 有限理性
↓
系统陷阱：政策阻力、公地悲剧、目标侵蚀、竞争升级、富者愈富、转嫁负担、规避规则、目标错位
↓
改变系统：从参数到范式，越深层杠杆越大
↓
行动方式：观察节拍、公开心智模型、尊重信息、关注整体、制定反馈政策、保持谦逊
↓
最终能力：不再只修补事件，而是理解结构、寻找杠杆、与系统共舞。
已成功兑换虚拟卡「Abyssvpn不限时1000G流量订阅」。
@thales #31 生产力改变生产关系，生产关系反作用于生产力，
当前研发体系下，如何放大AI生产力，可以关注 公众号：spec-first， 这里聚焦如何通过VibOps来释放生产力，解决传统研发流程中的问题。
大会分享：https://www.bagevent.com/event/9156636?sId=97044&moduleId=1161012
加微信拉入 企业级AI研发效能探讨：https://github.com/sunrain520/spec-first 【github readme加入群聊】
与业界大牛一起探讨 AI 与第二大脑、超级个体、企业研发效能的落地实践。
官网： www.spec-first.cn
VibOps 的核心研发 Harness——spec-first 已开源：https://github.com/sunrain520/spec-first
各位好。
一开始，我们真的没想做一个开源项目，更没想创造一个新概念。
我们只是想解决自己公司团队里一个越来越严重的问题：
AI 写代码越来越快了，但产品、研发、测试之间的协作，并没有同步变快，编码越快，bug反而越多。
甚至在一些复杂需求里，AI 越强，团队反而越乱。
不断试错中我们总结出来这套从需求到交付的协作链，从现有的bizDevops低成本落地成一套 AI 产研测协同方案，我们把它叫做：VibOps
2026 年 7 月 25 日，我也在深圳 DataFun × Agentic AI Summit 上公开分享了这套内部实践。
大会分享完后我更确定：我们要解决的不是“哪个 AI Coding 工具更强”，而是 AI 进入团队以后，一条需求怎样保持连续，一次交付怎样被真正证明。如何通过优化协作流程，进一步放大节点的AI生产力，提升团队整体的研发效能。
一、AI 写代码已经很快了，为什么团队还是很累？
如果只看 IDE，效率确实提升得很明显：接口、页面、单测、重构，以前按天算的工作，现在可能按小时推进。
但把镜头从“一个工程师写代码”拉远到“一条需求从提出到上线”，画风马上就变了。
1. 需求还没说清，AI 已经把代码写完了
PRD 里写一句“支持批量处理”，真正开发时马上会冒出一堆问题：
- 中间一条失败，是全部回滚还是部分成功？
- 失败项能不能重试、导出？
- 重复提交、权限和状态怎么处理？
- 怎样才算验收通过？
以前人工编码慢，研发还可能在实现过程中停下来追问。
现在 AI 会根据已有上下文，非常流畅地替团队补齐那些尚未做出的业务决策。
一个没说清的需求，更快地变成了一套看起来很完整的错误实现。
2. 群里“通知过”，不等于需求真的更新了
需求变化经常散落在群聊、会议纪要、接口文档和 Bug 评论里。
于是产品以为需求已经变了，研发还在按旧 PRD 实现，测试拿到的又是另一版用例。
到提测时，熟悉的对话就来了：
“这个不是早就改了吗？”
“哪里改的？PRD 里没有啊。”
“我在群里说过了。”
“那这个到底算 Bug，还是需求变更？”
每个人都没有故意漏传，但团队已经失去了“当前哪一版才算数”的共同答案。
3. 会议越来越多，因为大家在重复恢复上下文
很多会议不是在做新决策，而是在重复：
再讲一次需求背景；
再确认上次到底定了什么；
再找历史 Owner 解释旧系统；
再对一次 PRD、API、代码和测试是不是同一版；
再追一次谁还没确认、谁在等谁。
会议慢慢从“决策机制”变成了“上下文修复机制”。4. AI 把错误、Bug 和返工一起批量化了
AI 没有制造这些协作问题，但它拿掉了原来的速度限制器。
一旦需求不完整、上下文过期、验收标准不清晰，它可以同时修改多个模块，为错误理解补齐接口和异常分支，再生成一组能够证明当前实现“没问题”的测试。
流水线可能是绿的，因为它验证的是“代码是否符合当前实现”，不一定是“实现是否符合业务真正想要的东西”。
测试于是被迫成为需求补全者、版本核对者和跨角色争议裁判者。
5. 每个人都完成了任务，需求却没有完成
产品说 PRD 写完了，研发说代码合并了，测试说用例执行完了，发布说流水线成功了。
但团队仍可能回答不了：
代码覆盖的是不是当前有效需求？
测试验证的是不是同一版业务口径？
业务 Owner 是否真正验收？
还有什么残留风险？
这次的方案、Bug 根因和验证经验，下次还能不能找到？
局部任务全部完成，不等于同一个需求已经被完整交付。整条链路最终变成：
需求质量不足且持续变化
→ 产品、研发、测试拿到不同版本
→ AI 基于残缺上下文高速执行
→ 错误实现和返工批量化
→ 团队用更多会议、追人和手工同步补洞
→ 每个节点都很忙，端到端交付仍然延迟AI 只是把原本被缓慢编码速度遮住的团队协作问题暴露、放大了出来。
研发流程中真正的新瓶颈变成了：谁来维持需求连续性，谁来保证各角色拿到的是同一个事实，谁来证明需求真的完成了。
我原本以为，这只是我们公司的问题。
大会交流后发现这些场景在不同规模、不同技术栈、不同组织结构的团队里都在重复发生：
创业公司说需求变化太快，PRD 根本来不及更新；
大厂团队说跨部门协作链太长，光对齐就要开好几轮会；
外包团队说客户需求总在变，但合同和交付物对不上；
平台型公司说多条业务线共用一套系统，每次改动都要反复确认影响范围。组织形态不同，但痛点的结构是一样的：需求在传递中丢失连续性，团队拿到的不是同一个事实，完成的判断标准不统一。
企业真正面临的问题：AI生产力提升，放大了企业协同关系的劣势！！！
我们要解决的可能不只是"自己公司怎么用好 AI"，而是一个在 AI 时代被放大的、跨行业的协作结构问题。
二、一个已经跑过的真实场景
只讲痛点和架构不够，还是要看这套东西有没有进入真实研发。
我们在 App 双端场景里遇到过一个典型问题：同一份 PRD 进入研发后，Android 和 iOS 会根据各自拿到的产品说明、设计稿和历史代码，再分别理解一次需求。
两端最后出现差异，很多时候不是谁技术不行，而是从一开始拿到的需求事实就不完全相同。
后来我们把它改成：
同一个需求身份
→ 同一套设计事实和 Context Snapshot
→ 共同的 Contract 与验收标准
→ 一条需求主线内完成 Android 和 iOS
→ 双端差异检查
→ 测试 Evidence
→ Owner Acceptance在当前已经完成的 App 双端样本中，我们用这种方式跑完了 7 个真实需求：
一名研发可以在同一条需求主线内贯通 Android 和 iOS 交付；
当前样本交付效率提升 45%；
Bug 减少 80% 以上。边界也必须说清楚：这是 App 双端场景 n=7 的阶段性结果，不代表全组织，也不能直接外推到其他团队。
“单人双端交付”也不等于一个人替代两个专业团队。组件、架构、性能、安全和高风险 Review，仍然需要专业角色守住。
真正被验证的是：
当两端共享同一套可执行的需求事实，重复理解、往返对齐和末端返工才有机会真正减少。
同一个需求也留下了 Workspace、双端方案、Android/iOS Diff、测试 Evidence 和验收结果。这至少证明 VibOps 不只存在于架构图里，已经进入过真实研发现场。
三、我们缺的不是另一个 AI Coding 工具
为了解决这些问题，我们研究和实践过 Spec Kit、OpenSpec、BMAD-METHOD、Superpowers、gsd，以及 Claude Code、Codex 自带的 Skills、Rules 和 Agent 能力。
这些项目都解决了重要问题：有人擅长规范驱动，有人擅长 Spec 变更，有人擅长多 Agent，有人擅长 TDD 和独立验证，有人擅长对抗长任务中的上下文腐烂。
但真实团队的问题经常发生在它们之间的接缝：
`Spec 在代码仓库里，需求变化却在群聊里
计划在 Agent 会话里，任务状态却在另一个系统里
CI 能证明代码通过了检查，却不知道原始验收目标是什么
知识库保存了历史文档，却不知道哪次交付让旧知识失效`
每个工具都可能正确完成了自己的工作，但把它们重新拼成“同一个需求”的，仍然是产品、研发、测试和项目负责人有限的注意力。
所以我们不想替换 GitLab、CI、项目管理工具、知识库或 AI Coding 宿主。
我们想补的是它们之间缺少的那层需求级协作与控制机制。
这就是 VibOps 的起点。
四、VibOps 到底是什么？
一句话定义：
VibOps 是以 Work Object 为统一交付身份，以 Workspace 为人和 Agent 的协作空间，以规范化交付物为协作契约，以 Evidence 为完成依据，以企业知识进化为长期价值的 AI 产研测协同解决方案。
翻译成人话，就是“五个一”：
一个需求身份：产品需求、代码、测试、发布和验收都属于同一件事。
一个 Workspace：人、Agent、知识、规范、代码和当前状态共享同一个需求现场。
一套交付契约：PRD、技术方案、API、测试策略和验收标准有版本、有评审、有完成条件。
一条 Evidence 链：Agent 说完成不算完成，真实命令、Diff、测试、发布记录和业务验收才算。
一个知识闭环：每次交付产生的决策、Bug 根因、验证经验和 Skill，经过治理后反哺下一次需求。
VibOps 不是要求所有公司采用同一套固定流程，而是希望提供一套可以按技术栈、组织规模和风险等级装配的协作内核。
把这“五个一”展开后，VibOps 的完整运行关系如下：同一个 Work Object 被六层责任链持续承接，四道 Gate 控制事实、执行、Evidence 和归档，三条轨道分别保障交付、沟通感知与知识进化。图中的虚线部分表示仍在加强的端到端 Evidence 关联，不等同于已经完成全面覆盖。
五、spec-first 在 VibOps 中是什么位置？
spec-first 不是 VibOps 的全部。
它是 VibOps 中已经开源、最接近开发者的一层，负责守住从需求意图到可信代码变更这段工程链：
Intent → Spec → Plan → Tasks → Code → Review → Knowledge
它的完整执行方式并不是把七个阶段机械串起来，而是让主链、可选文档审查、失败调试回流和项目工件共同形成闭环
三者的边界可以这样看：
层次 主要负责什么
VibOps 需求身份、Workspace、跨角色交付物、阶段 Gate、业务验收、归档和知识回流
spec-first Spec、Plan、Tasks、受控代码修改、Review、验证证据、残留风险和项目知识
既有工程系统 Git/MR、CI、测试平台、制品、部署、监控等企业事实；VibOps 负责关联，不重新复制
所以，今天安装 spec-first，最先能够验证的是中间这段：怎样把一次临时 AI Coding 对话，变成由项目拥有、可以 Review、可以交接、完成声明受证据约束的工程变更。
群聊里的需求变化如何回写、产品研发测试如何共享 Workspace、发布后如何业务验收，属于更完整的 VibOps 平台与团队协作层，不能假装安装一个 npm 包就全部解决。
六、当前做到哪里了？
为了不把架构目标写成已经完成的现状，我们把证据分成三层：
状态 当前边界
已经在真实场景运行 需求级 Workspace、Context Snapshot、Contract、spec-first、受控执行、Evidence 与归档主链；App 双端、Admin 跨栈和低风险小需求产生过同源工件
平台已经具备并持续演进 六阶段流程、交付物与评审、规范模板、企业知识库、AI 工作区、Skills/MCP/Rules、成员权限、发布单和 Open API
仍在重点加强 独立一等 Work Object，以及 Commit/MR、CI、测试、制品、部署、运行验证和业务验收之间更完整的端到端 Evidence 关联
我们的表达纪律是：
“已实现”要有能力工件
“已运行”要有同一需求的真实执行链
“已改善”要有基线、样本、趋势和归因
大会分享只能证明我们把这套实践公开讲了出来，不能证明它已经适配所有公司。
但在不同项目、技术栈、仓库结构和 AI Coding 宿主中持续验证后，加上第一节描述的那些痛点在各类团队交流中反复被确认，我们越来越确定：
这些痛点是跨行业、跨规模、跨技术栈的共性问题。AI 放大了它，但它本身一直存在。
创业公司、大厂、外包团队、平台型组织，组织形态完全不同，但都在面对同一个结构性困境：需求在传递中丢失连续性，团队拿到的不是同一个事实，完成的判断标准不统一。
所以我决定来 L 站开帖：不是因为 VibOps 已经通用，而是因为这个问题足够通用，值得所有遇到类似痛点的团队一起验证、质疑和修正。
我们在自己公司验证过它能跑，但它能不能适配你的单体/微服务架构、你的前后端分离/全栈团队、你的敏捷/瀑布流程、你的多产品线/多 BU 协作——这些问题，只有更多真实团队用起来才能回答。
七、先试试 spec-first
https://github.com/sunrain520/spec-first
前置条件：Node.js >=20.0.0、npm、Git，以及 Claude Code 或 Codex 等受支持宿主。在需要启用的 Git 仓库根目录执行：
npm install -g spec-first
spec-first quickstart
初始化并重启宿主后，在宿主会话中运行：
spec-runtime-setup
spec-brainstorm "为现有系统增加用户操作审计功能"
对于值得持久化的需求，它通常会先形成：
docs/plans/YYYY-MM-DD-NNN-<type>-<topic>-plan.md
这份需求产物属于项目，可以进入 Git、接受 Review、跨会话继承，再继续交给 spec-plan 深化。
目前 Claude Code 和 Codex 是主要支持宿主；Kiro、Qoder、Cursor 和 OpenCode 等宿主处于不同程度的 preview 阶段。生成 runtime 文件不等于所有宿主都已完成实机验证。
八、先开个帖，后面慢慢更新
写到这里，先把丑话说在前面：VibOps 和 spec-first 现在能跑，也确实解决了我们团队的一些问题，但离“拿来就能适配所有团队”还差得远。
小需求用起来可能嫌重，第一次接入也要花点时间；不同宿主的支持程度不一样，企业里的 Git、CI、测试和发布系统更是各有各的脾气。Evidence 能减少“嘴上说完成”，但挡不住模型犯错。还有一些设计，我们自己也说不准究竟是通用经验，还是只适合目前的团队。
所以先在这里开个帖，不急着把它包装成一个已经完成的产品。
后面有新版本、真实需求案例、单仓和多仓实践、踩坑记录，或者哪次改崩了，我都会回来更新。
如果你愿意，可以把 spec-first 拿到自己的项目里跑一跑。哪里太重、哪里别扭、哪个宿主跑不起来，直接说就行。最好能顺手带上这些信息，我也方便复现和改进：
项目类型：单体还是微服务、前后端分离还是全栈、单仓还是多仓
团队结构：创业小团队、大厂多 BU 协作、外包/甲方对接、还是平台型多产品线
使用的 AI Coding 宿主：Claude Code、Codex、Cursor 还是其他
卡住的具体步骤：初始化、生成 Plan、执行 Tasks，还是 Review/归档环节
特别想听多体系公司团队的反馈：如果你们是多条业务线共用基础设施、跨部门协作链很长、或者不同团队技术栈不统一，VibOps 这套"统一需求身份 + 共享 Workspace"的思路在你们那里能不能跑通、会撞上什么墙，这些是我们目前样本覆盖不到的场景。
好用的话欢迎点个 Star；不好用就提 Issue，吐槽也行。
这个帖子不准备发完就走。希望能和大家边用边改，把 spec-first 和背后的 VibOps 慢慢磨得更扎实一点。