老板们 你们公司 AI 是如何落地到实际项目的啊

[shanex]

公司人均 copilot ，让大伙儿去探索 AI 如何结合实际项目或者帮助提升工作效率

有没有实践过的老板，抄下作业!

---

目前就是 chat 和 agent 模式下写写代码，找找 skill ，然后结合 mcp 玩玩，

更深入的，结合自动化的还没接触过，感觉玩不出什么花样。

之前看有人吹 2 倍 3 倍 10 倍工作效率提升匪夷所思

[peteretep]

agent 从 0 开始做玩具 1.0 那有 10 倍

玩具 2.0 开始，那就开始 从 10 倍变为 0.1 倍了

[vba]

比较好奇 github copilot 怎么开公司发票报销，有正规途径吗

[shanex]

@vba 还真不知道

[swananan]

不看代码的，可以有 10 倍，不过没有意义，工作量只是被转移了

[RRRSSS]

@vba 开个 team 的商业版本就行了

[yoshiyuki]

@peteretep 10 倍变为 0.1 倍，那现在所有用 AI 辅助编程的公司团队，从老板到程序员全都是傻子吗？

[peteretep]

@yoshiyuki #6 你自己是 1 倍， ai 是 10 ， 加起来 11. ai 在复杂的时候会变为 0.1 ， 总共就是 1.1 。 主要看你怎么用

[yoshiyuki]

@peteretep 提问：如果 AI 不是 0.1 ，就证明项目还不够复杂吗？

[peteretep]

@yoshiyuki #8 是逻辑深度不够

[yoshiyuki]

@peteretep 原来是逻辑深度不够。 也就是说，所有全部外面公司团队用 AI 编程用得很好的，他们的产品工程逻辑深度都很浅

[peteretep]

@yoshiyuki #10 你对

[yoshiyuki]

@peteretep 我什么都没说啊，都是你说啊

[Yue153]

10 倍都是自媒体吧，不这样写你怎么会点开呢？没用，和你老板说，别 FOMO 都是噱头，最终还得是人来 owner

[94]

@yoshiyuki #10 ，有一定原因，很多复杂需求用话都很难描述明白。如果前期 PRD 写的不错，开发前也和 AI 多轮对话也把开发计划写的很细致（具体到模块细节）。其实也已经付出了成本，只不过把成本从开发阶段前置了。这个时候用 AI 真的是提效，因为需求已经拆解的非常明确了。即使让 P5 级别的开发也能很好的产出，只剩下了人天问题。

但即使前期工作做了非常完备了，现在我身边因为 AI 快速编程出现的问题也已经不少了。还是资深开发搭配 AI 产出的中等规模项目，陆陆续续开始出现问题。真的是非常资深的开发，我是自认比不上的。关键崩的还很离谱，达到服务完全不可用的情况。
AI 产出太快了，完全没办法细致的 review 。跑通测试用例，自动化测试也能过，功能就可以上线了。如果企业自身不重视测试环节，因为降本增效砍掉了测试岗，问题出现的会更快。

[yoshiyuki]

@94 [AI 产出太快了，完全没办法细致的 review 。] 可是 AI 不会阻止你去 review 代码，这听起来更像是自己放弃了 review 和质量控制，转头甩锅给 AI

[94]

@yoshiyuki #15 ，长期使用 AI ，不可避免会变成这样。得看你怎么样的使用程度了。高强度、深度使用的场景下，我的身边案例最终都是有这个问题（已经排除初中级开发 VibeCoding 的案例，全是 10 年以上老资历、在 Spec-Coding 名词出现之前就在用 Spec 模式开发的开发者）。

[94]

@yoshiyuki #15 ，有点类似于这个帖子 👉 /t/1188948
文中提到的 [最接近的词可能是"掌控感"，一种"我能搞定一切"的幻觉] 的状态。但是没有那么奔放，还是严谨按照我上面提到的工作方式在走。
会让人无限的膨胀，因为提效真的太多了。最终瓶颈出现在人的部分。

其实原本的情况下这些资深开发会拆分好开发工作，把大部分的的开发工作交给其他的 IC 来进行，且因为人的效率问题，基本上都是可以做到有富足的时间可以好好 review 每一个 PR 。但是 AI 是不知疲倦的。
让你我同时指挥 N 多个高能量的 P6 、P7 开发不知疲倦的产出，也会因为相信他们的能力而逐渐放开 review 的权限，而只在核心模块分配有限的精力。直到出现问题开始人工介入。

[yoshiyuki]

@94 但是我们现在都已经知道了 AI 只能在极小范围内表现出 P6P7 级别的规划编码能力，不能放任无 review 状态，还抱着过去的弊端行为看待 AI 工作，应该要尝试新的工作方式结合 AI 而不是固步自封吧

[94]

@yoshiyuki #18 ，整体的模块设计是多轮对话输出的明细 Plan ，并不是一个大空的计划。而是细节到某一个模块的某一个函数级别。所以是交付给 P5 都可以实现功能的情况。
并且产出极快，而且各种测试流程跑下来都没有问题。这种模式在持续运行将近一年都没有出现问题的情况下，换成你也会放松警惕的。好好去 Review 只是在设想中。真的铺开来用的时候是很难保证每一个 PR ，每一个 Commit 都有被好好检查过。还是那个问题，瓶颈出现在人这边。各种概念的 “人祸” 上面。

[yoshiyuki]

@94 那说到底还是团队菜了，因为现实中有大公司成功落地用 AI 进行大量开发并且没有搞出大事故，一如 cursor 公司

[94]

@yoshiyuki #20 ，Cursor 其实问题也很多，特别是一开始的时候，虽然没有崩到不可用的地步，但也是有 Chat 对话故障的情况。
即使现在也依然能够看到 Cursor 一天更新两三个版本的情况。

但不重要，其实问题不在这里，而是公司关于人员投入成本的限制。很明显 Cursor 是以团队的方式来运作的。而现在我们这边很多公司想以一两个资深开发搭配 AI 来当作千军万马来用。