ysoseriousC

@inc3ption 我觉得都花不了十分钟，但就是不让用。而且为个这个破活儿我还要担风险。。不如摆烂

@xiangran0028 这种公司，这种项目我也是头回遇到。但救火就是这样，没办法。之前遇到的项目有的还要代码和注释严格 1:1 的。

@nbndco 最后是用 powershell 脚本做的，批量查关联文件列表里的关键词列表的存在行数。。

@Sh1xin 不好意思，可能我的表述不是很清晰。从我这里能了解到的情况有限，我能知道的是：
甲方（可能）需要一个关于此次 release 的某个功能的代码行数。
上面管理为了满足这个需求，在知道这项目状况（管理和）的情况下，让我们拿 AI 去做这个事儿，并且知道结果不可靠。
我们进行了执行。

补充背景：我们整个小团队被拉来救火填坑的。。

@aptandatp 有版本管理（这个出事儿的项目是 svn 的），没有提交规范，并且现在来做事儿的全是来救火的。。

@nnnnnnamgn 企业版可能他们做了隐私策略限制，必须手动标记打开的文件，不然 copilot 会思考完了问你，请给我提供 XXX.js 的代码。而恰巧这个任务就是需要全局理解业务找到关联目录统计。。

@qeqv 额，是我没说明白需求，需求到 PM 这一层已经变成了：要关于这块大功能修改的代码行数。
有内味儿了吧…

@woodfizky 我和你想的一样啊。。这个事儿往前倒从根源上就有问题。然后中间的每一步都应该有人站出来阻止并且提供解决方案。但所有人都是不担责不背锅的心态去干的话，项目就会以这种诡异的形态存在着。

@HeyWeGo
@zisen
是的，发起这个任务的 PM 就是想糊弄，出了问题推给 AI 呗。AI 出来之前我们可以直接推脱这种工作做不了，结果不可靠。但现在他们直接点名要 AI 结果了，就很难评价。

结果不重要，有结果很重要。