月底发版。
客户问：这次改了什么？
合理的问题。但，
我们没有 branch 。没有 commit 规范。两个月的改动，全堆在一起，没有人能回答这个问题。
PM 灵感来了：用 AI 来梳理。
上面指定用 企业账号的 Copilot 。
Copilot 的实力 做不了。
没关系。公司有自研工具。
合规，安全，放心用。
是一个 EXE 。
套的 GPT 的壳。
gpt4o 。
还限制很多。
不支持上传文件。
不支持流式输出。
上下文窗口很小。
还不如 Copilot 。
指示是
我们把两个月的代码差异，手动切碎，一块一块喂进去，等它憋出结果，再人肉拼接。
最后告诉上面：这些文件改了这些行数。
流程管理混乱，没人知道改了什么
用 AI 查，选了个不能用的工具
换了个残废的工具，人肉补全残废工具的能力，交付。
每一步都有它的理由。
在日本干久了，本来应该见怪不怪的。
偶尔还是会有一些新操作，让我平静的发疯。
原来还能这样用啊。
 |
1
Aruforce 3 月 25 日 via Android  1
没有 branch commit message 乱写 这不是你们人的问题么？
|
 |
2
ysoseriousC OP @Aruforce 是的，是因为这项目原先的技术 Leader 被办公室政治搞走了，现在我们救火烂摊子。所以基建流程上全是槽点，没人推着解决
|
 |
3
msg7086 3 月 25 日
啥？日本公司？
|
|
4
ysoseriousC OP @msg7086 这种事儿感觉很难在国内发生吧。。全世界应该只有日本会这样
|
 |
5
zisen 3 月 25 日
之前看一个视频段子说日本企业采购电脑非要采购那种老一代的，原因是新电脑太快了，导致人要跟上电脑的速度，用老电脑很卡的话就可以边摸鱼边干了
|
|
6
msg7086 3 月 25 日 1
@ysoseriousC 感觉真是连印度人都不如啊……
|
|
7
ysoseriousC OP @zisen 听起来很夸张，但没有自信说绝对不可能。现在发生什么我都不奇怪了
|
 |
8
HeyWeGo 3 月 25 日
只要个结果，而且这个结果不可验证，那么试试看糊弄呢
|
 |
10
woodfizky 3 月 25 日
不是，怎么这么多槽点。。
以前没上 git 或者其它版本管理，那你们有改动前的代码和改动后的代码？ 那本地随便新建一个 git 仓库，先把旧代码扔上去 commit 一次，再把新代码覆盖进去，逐个代码差异看不就好了吗？ 还有发版被客户问改了什么，这纯属你们公司管理流程问题了。不知道改了什么，发什么版？ 开发闲的没事干改代码玩？总得有个人告诉你们什么要改吧，那改了之后就不记得了吗？ |
|
11
ysoseriousC OP 1
|
|
12
ysoseriousC OP @woodfizky 我和你想的一样啊。。这个事儿往前倒从根源上就有问题。然后中间的每一步都应该有人站出来阻止并且提供解决方案。但所有人都是不担责不背锅的心态去干的话，项目就会以这种诡异的形态存在着。
|
 |
13
lian3204321 3 月 25 日
看到日本公司，我觉得就正常了
|
 |
14
sn0wdr1am 3 月 25 日
日本公司，不是号称很严谨的吗》
|
 |
15
egen 3 月 25 日
|
 |
17
qeqv 3 月 25 日
两个月改动堆一起，是不是其实回复客户改了什么也并不需要很详细？找几个最近的大提交看一下改了什么告知客户就行了呗
|
|
18
ysoseriousC OP @qeqv 额，是我没说明白需求，需求到 PM 这一层已经变成了：要关于这块大功能修改的代码行数。
有内味儿了吧… |
 |
19
nnnnnnamgn 3 月 25 日
没用过企业的 copilot ，但感觉 pro 订阅用 sonnet4.6 就能搞定这种任务，还是说代码太多了？
|
 |
20
aptandatp 3 月 25 日
copilot 不够吗？我觉得挺厉害的。
不过你们这个没有 git 管理的软件公司也太抽象了。 |
 |
21
javalaw2010 3 月 25 日
最后结果是什么不重要，结果准不准确也不重要，没有人类背锅这件事很重要。
|
|
22
ysoseriousC OP @nnnnnnamgn 企业版可能他们做了隐私策略限制，必须手动标记打开的文件，不然 copilot 会思考完了问你，请给我提供 XXX.js 的代码。而恰巧这个任务就是需要全局理解业务找到关联目录统计。。
|
|
23
ysoseriousC OP @aptandatp 有版本管理（这个出事儿的项目是 svn 的），没有提交规范，并且现在来做事儿的全是来救火的。。
|
 |
24
Sh1xin 3 月 25 日
看了前面的回答，有点奇怪。这明明是代码管理有问题，客户质询变更和交付内容后无法提供准确信息，只能用 AI 跑个结然后糊弄甲方。这和客户本身性质有什么关系。难道说对此无所谓的甲方才是好甲方吗，不能理解
|
|
25
ysoseriousC OP @Sh1xin 不好意思，可能我的表述不是很清晰。从我这里能了解到的情况有限，我能知道的是：
甲方（可能）需要一个关于此次 release 的某个功能的代码行数。 上面管理为了满足这个需求，在知道这项目状况（管理和）的情况下，让我们拿 AI 去做这个事儿，并且知道结果不可靠。 我们进行了执行。 补充背景：我们整个小团队被拉来救火填坑的。。 |
 |
26
FireKey 3 月 25 日
既然是上面指定了工具你们随便让 ai 跑下呗,让 ai 编个回答.出错了让上面鞠个躬就好了.
|
 |
27
Baoni 3 月 25 日
日本公司估计要爱死 AI 了，以前还需要亲自造假，还得为自己鞠躬。现在都推给 AI ，鞠躬都更轻松了。
|
 |
28
nbndco 3 月 25 日 via iPhone
你直接跑个 diff 然后全部交给 copilot 不就好了，它读不了你帮他读
|
|
29
ysoseriousC OP @nbndco 最后是用 powershell 脚本做的，批量查关联文件列表里的关键词列表的存在行数。。
|
 |
30
xiangran0028 3 月 25 日
你这是什么公司？我们和日本好几个公司合作过项目，都非常严谨，根本不可能允许你说的这种情况出现，任何软件和硬件设计上的修改都要说明原因，可能造成什么问题。
|
 |
31
kandaakihito 3 月 25 日
狠狠项目了，想去这种公司，估计很适合我这种滥竽充数的菜鸡苟下去
|
|
32
kandaakihito 3 月 25 日
@kandaakihito 项目 -> 羡慕
|
|
33
ysoseriousC OP @xiangran0028 这种公司，这种项目我也是头回遇到。但救火就是这样，没办法。之前遇到的项目有的还要代码和注释严格 1:1 的。
|
 |
34
inc3ption 3 月 25 日
想办法把代码搞出来，起点 commit 和 终点 commit 丢给 claude code ，十分钟给你输出两千字的版本变化
|
|
35
ysoseriousC OP @inc3ption 我觉得都花不了十分钟，但就是不让用。而且为个这个破活儿我还要担风险。。不如摆烂
 |
 |
36
uxstone 3 月 25 日
上面的人都不在意质量，下面的人也没必要考虑太多。
胡编乱造不就行了。 |
Select Language