※ 引述《strlen (strlen)》之铭言：
: Incremental implementation with continuous
validation
: Execution happens one component at a time, with validation at each step.
AI
: translates COBOL logic into modern languages, creates API wrappers
around
: legacy components that stay in place, and builds the scaffolding to run
old
: and new code side by side during
transition.
:
: Each step either succeeds and gets validated, or fails and gets
corrected
: while the scope is
small.
:
: You never have massive changes in flight where failure means rolling
back
: weeks of work. As your team sees modernized components passing tests,
they
: gain confidence to tackle progressively more complex parts of the
system.
:
: 英文不好喔？
GOOGLE Translate:
采用持续验证的增量式实现
执行过程一次只执行一个元件，并在每个步骤进行验证。人工智能将 【COBOL 逻辑】翻译成
现代语言，为保留的旧元件会建立 API 封装，并建立鹰架，以便在过渡期间并行运行新旧程式码。
程式码。
注: 我的重点是...谁来验证它整理的结果的正确性?

会先 build tests 吧

这时候就是人工标注派上用场的时候，手动让自动生成出来的测试知道怎么样才通过的标记

哦,先为cobol写unitest?

这不就是重构的其中一个技巧 没AI不也做得到

10年来也一堆银行在把cobol改写成Java或C#，还好吧

TW的老Core Banking, 一直都在Cobol, Basic手上,纯网银有Java的，C#的没听说。其中一家本土的三天两头停机的。

台新C#

台新?Core Banking呢? Bancs+HP superDom. 哪来C#?

新银行都会新旧系统并行一阵子，交叉验证结果一致老行库没人敢动，都想撑到退休后就是别人的事动了有事就是你的事，没事不是你的事。老行库找的那些资讯人员?外包人员?哈

动了就有kpi当然会想动呗 看要java或者golang然后补测资再补充是字面上的测资 而不是拿什么系统整合测试吐的log

重点不是KPI，重点是谁摃?你知CORE BANKING出事,金管会来聊天的话，下半年的绩效就没了，甚致连总经理都要停职。再说测资? 哪里来? 够不够全面? 还是..谁来摃?

重点是动了的报酬是否值得承担带来的风险Claude 的立场是尽量推广，blog 的内容会鼓励改COBOL但到头来关键在是否真的有维护COBOL系统的人买单。

可能大家工作久了，忘了你只是负责【维护】不是所有人.【维护】的人想买单，是要摃起银行总经理(所有人)的责?

查了一下新闻 台新上线五年多了 信用卡的部分

出包连总经理都要停职喔@@...

Cobol跟C#并行运作不知道结束没

我觉得话题性大于实际发生的机率 银行要拍版干这事太难了非银行的其他企业 还有微小的机率是老板霸气拍板硬干下去

银行的Core Banking要换，基本上都是董事长要出来讲话然后总经理出面叫各山头配合。

难，目前几家核心换的太惨烈Doamin也都断层，短时应该不敢动银行容错低又老旧，出错风险太大

这东西要不要弄而已哪有这么难...上面推文就有解法了真怀疑各位是不是真的工程师耶 新系统做好当然是先当备援系统 旧系统吃什么 新系统就吃什么 旧系统吐什么 新系统吐的再拿去跟旧的比对 跑个半年一年 就可以切过去了

楼上完全不懂银行业银行出包，金额可能是几亿到几千亿所以cobol完全没人敢改..

银行跟其他私企的差别在还有个金管会 就算是董事长我都不觉得敢拍板说“大力改下去我来扛”XD

所以是政策问题不是方法问题 那没啥好说的啊你今天不给AI改也不会给人类改 永远放给它烂

cobol一直都不是技术问题阿...技术上做得到但没人敢动工作考虑的本来就不是只有技术问题而已

从自驾就知道，社会是靠人在运作 谁要扛(刑)责

只看技术才是最大误区省了这点钱跟时间可不够赔的

真的以为都是modular clean code？一个元件一个元件移植？ha ha，I have a bridge to sell you

推从自驾就知道+1

真的话都给你各位讲就好 在那边质疑AI难道能改陈年屎山代码吗？我看是不行吧？现在跟你说可以了 你又说屎山代码没人敢改 没人敢负责 改坏了你要修吗？那这不就代表找人类工程师来 也不敢改？这是不想改不敢改而不是不能改吧不敢给AI改 也不敢给人改 然后在那边笑AI改不动屎山 可悲

觉得AI吹真的很难沟通XD银行的问题就不在那边

一两年前我的心态跟 strlen 差不多但是他喵的真的进步太快了最近用AI的时候它已经能做到超过我的预期了我开始反思我的小脑袋是不是太慢了

是因为有小丑在吹AI能改屎山吧?根本没人说人类能去改屎山啊 事实是人类AI都不会改屎山会摆在那就是没有动的必要AI有这么多事能做 你想到的是拿去改屎山 笑死

南山换系统给你看了，下一个谁敢？屎山顺顺的用不好？不是大家不想改，只是血淋淋的教训那么多，只有傻子才会认为他天纵英明他不一样。要转换系统本来就不容易，不是只有软件Mainframe的稳定性也是ibm的护城河。然后先把claude code的bugs解一下。骂多久了，ai不是很神？还是ai创造更多屎山https://github.com/anthropics/claude-code/issues

台新就是我的主用银行啊 我知道有个Richart看起来很新但是我开完数位户头以后用了几次发现没任何好处就不用了现在还是用本来的App+网银 没又因去用Richart所以基本上这种东西都会是新系统和屎山并行但是因为屎山大家用的好好的 所以退场会退的很慢而银行需要负担这长时间退场的额外费用 所以诱因也不大想做的银行会做 台新就是 但就不会是个风潮 会发生但很慢这和一些Rust口水战很像吧 Rust要拿来写新的lib我看起来没啥问题 也可能开始在新专案相对快速抢C/C++市场但是大家已经用的好好的轮子库想要Rust全重写就很不现实这就不是技术问题 是人的问题 所以云社畜都体会不到那生活是很惬意了喔有人懒得去查南山事件的话2019年底南山人寿花百亿台币把SAP从IBM换成别家*ERP结果出一大堆问题 行政/商业流程也被抓瑕疵最后金管会罚南山4000万 董事长被停职2年 总稽核扣30％薪

Richart 是信用卡系统，不是Core Banking。南山是换成SAP ERP。看来是AI 提示有错?

是我打错字 XDRichart有银行服务，但是我不知道后面的金融系统是独立的还是共用的https://ibb.co/qYRHWyJM 我不知道二类帐户是什么意思XD喔线上验证的帐户吗 但如果后面还是同一个Core Banking只是branding的话就代表台新也没在动吧应该

台新的Richart = 网银+行银。后面介接卡和Core Banking而台新的C#的信用卡【相关】系统，刚好多两个字。如果【相关】系统算该系统的问话，哪么台湾Java超十年.

那看起来是完全没动到 XD

老话一句... 谁负责? 出事 anthropic 扛吗?COBOL 动不了的部分... 大多都不是说扛就扛的...

指标行肯做就有办法下去 不过 007 这类的反而不敢做

肯做？我不信有上头敢说我来扛 哈哈

"要不要弄而已哪有这么难"..? 勿忘南山难的不是coding 是业务逻辑潜规则或是魔术资讯太多当前AI也是学写code而已，等到哪天你愿意让AI扫内部资料包含一些死人骨头的骨灰后 再来说要不要弄而已哪有这么难

勿忘DOGE