原创案例页
很多团队不是不会试 AI，而是要么推得太猛，要么拖得太散。这页讲的是一种更像正常团队会发生的节奏：先试点，再收边界，再慢慢扩，不靠一开始写一大本制度。
页面信息
第一步：先挑人和活
最稳的起点，不是“全员上线”，而是先挑两三个人，再挑两三类活，比如读项目、补测试、查 bug。人和活都别太多，这样团队才看得清到底哪块在起作用。
第二步：先收边界，不先谈大词
试点期最该先定的，不是 KPI，也不是 fancy 流程，而是边界：哪些仓库能碰，哪些命令先别放，哪些数据不许带出去，哪些权限要保守一点。
边界先立住，团队心里才不慌。否则一出问题，大家最先怀疑的不是流程，而是“这玩意是不是本来就不该上”。
第三步：统一最小动作
团队不需要一开始就完全统一，但至少要统一几件小事：怎么提需求、怎么验结果、怎么记录一次好用或不好用的案例。
如果每个人都按自己的脾气乱用，后面经验根本攒不起来，最后只会剩“有人说好用，有人说没用”。
第四步：别急着上最复杂那档
团队试点期最容易犯的错，就是刚有点甜头就想上 plugins、sub-agents、hooks、MCP 一整套。实际上，单人单任务都还没跑顺的时候，上这些只会让问题更难分辨。
试点要的是“看清楚”，不是“看上去很先进”。
第五步：把案例沉淀下来
团队真正能扩开，不是因为开了会，而是因为有几条真实案例能复用：什么任务适合、什么不适合、什么权限最稳、什么提问最容易得到好结果。
这也是为什么原创案例页有价值。它们不是在背原理，而是在告诉后来的人“这条路别人已经走过了”。