确实，单纯 coding 的天堑已经不再有了。AI 把绝壁变成了一个坡。是个人都能走上去了。

未来 AI 能不能再把这个坡变成平路我不知道。
我现在还是得要多几轮对话把代码结构整理成我要的形状。
万一哪天邪神降世 AI 暴毙，我可以继续的写下去。

像可控核裂变被实现的时候一样，它既可以提供能源也可以毁灭世界。AI 对人类必然也是有利有弊的。
组织岗位的变革我觉得还好，和历史的工业革命类似，阵痛期过了肯定会有新的平衡。

长远来看我最担心的是人类质量的延续问题，如果 AI 可以让人类的求知欲几乎瞬间被满足，会不会慢慢也就不再想学习了。
我现在就开始有这个倾向了，AI 出的方案只要出现我觉得不明觉厉的地方，我下意识认为就是对的，经常不会再深入了解了。
就像玩游戏，本来应该通过努力克服重重关卡，突然给了一个开挂的机会，开过之后游戏就索然无味了。

尽信 AI 不如无 AI，当知识 (智力) 不再重要，人还有什么价值？

我对论坛的历史就记得几个比较关键的节点。
测试布道师时期 (令人印象深刻的 monkey)， 霍格沃滋时期 (培训占了半壁江山)， 人工审核时期 (当前)

新团队是可以激进一些，因为本身就是带着探索标签的。
老团队的演进还是需要对当下信任的基础上，渐进式的改造。未来未来，DRP。

AI 跑 UI 自动化烧 token 那可是上亿上亿的烧。不知道一轮跑下来你那边 api 成本上万了没有。
后来我们痛定思痛，调研发现一种包月方案，虽然没有现在 Ai 这么智能，但 好歹成本固定下来了，做执行是完全没问题了。
那就是招几个外包
如果觉得用外包太抖机灵了，那只能减少 UI 自动化的场景集。 将大部分的自动化下沉到接口自动化。 只对 “核心 “” 交互用 UI 自动化。
另外在将界面元素传给 AI 前，工程化的手段做一下数据的裁剪和压缩。省点是点

真能无限推理的话，任何领域 AI 都可以远超人类，服务业的消失也是早晚的事儿～
AI 培育的食用 “猪”，靠光合作用就能长肉，肉料比无解。 AI 理发设备比现在的顶尖发型师剪的都好。
真有什么需要"人"才能做的，直接自己手搓一个完美受精卵好不好，我们额这些劣等人是没资格给 AI 打工的。
我能有幸在矩阵里一边当人肉电池一边通过脑机接口娱乐到死就知足了。

角色其实也没变吧，只是搬砖砌砖的动作有 “机器” 帮忙做了。全权托管的话，最后放眼看过去是个房子没错。可仔细一看，有的砖排列不对，有的水泥标号错了。

从个人经验来说，vibe coding 不做到工程类/方法维度的 “视如己出” 是很难长期维护的。

现在是有分歧的，资本方肯定希望能用电的就不用人。只是目前谁也说不清楚未来 AI 的边界在哪里。
只能赌 AI 的上下文边界还在算力存在极限，这样技术岗位就还能有活路。
如果上下文不再是卡点了，那真是无限推理的终结者时代了。遇事不决，加大电压

最大的逻辑问题，是把「AI 降低了代码修改门槛」等同于「业务人员具备了软件工程能力」。

我不反对让业务人员参与代码修改，但反对把这件事描述成程序员的价值正在从编码转向架构设计。

有几个问题值得重新思考。

第一，看到结果不等于知道结果正确。

页面正常不代表业务逻辑正确，功能跑通不代表没有破坏其他功能。

修改一个退款规则，可能影响订单状态、财务对账、报表统计和下游接口。业务人员看到当前页面正常，并不能证明整个系统正常。

软件工程解决的从来不只是代码能不能运行，而是如何证明系统在各种场景下都符合预期。

第二，系统知识显性化，不代表系统复杂性消失。

把文档补齐，把调用关系画出来，确实能降低理解成本。

但分布式事务、并发控制、数据一致性、缓存失效、接口兼容、故障恢复，这些不是画一张架构图就能掌握的。

知识可以共享，专业能力不能通过共享文档自动复制。

第三，业务决策权不等于技术实现权。

业务决定退款规则，不代表业务知道如何保证退款幂等。

业务决定排行榜权重，不代表业务知道如何避免全量计算导致数据库崩溃。

业务应该决定系统做什么，研发负责确保系统能够正确、稳定、安全地做到。

这不是信息壁垒，而是专业分工。

第四，AI 降低的是编码成本，不是系统风险。

以前修改一个功能需要两天，现在可能只需要一分钟。

但如果一天产生了 100 个改动，谁来保证它们之间没有冲突？谁来保证测试覆盖？谁来处理版本兼容？谁来负责线上事故？

单次修改成本下降，可能带来整体变更数量和系统治理成本的上升。

第五，文章对程序员的价值理解过于狭窄。

程序员的价值从来不只是掌握系统地图。

更重要的是建立抽象、控制复杂度、管理依赖、识别风险，以及让系统能够持续演进。

AI 能生成代码，不代表它天然理解整个系统的约束，更不代表提出需求的人能够判断生成代码的长期影响。

我真正想反驳的是：

不要把「业务人员可以通过 AI 修改代码」包装成「业务人员已经具备独立修改系统的能力」。

这两者之间还有很长的距离。

让业务人员直接修改低风险配置、页面展示和简单规则，是生产力进步。

让业务人员通过 AI 直接修改核心业务逻辑，却没有相应的测试、审查和责任机制，是把研发成本转化成了系统风险。

AI 时代，程序员确实不应该再把自己定位成代码搬运工。但也不能因为 AI 会写代码，就低估软件工程本身的复杂性。

代码越来越容易生成，真正稀缺的反而是判断一段代码能不能进入一个真实运行的复杂系统。

需要我帮你改得更口语化一点吗？

这种就是公说公有理婆说婆有理。

我们也用的 langgraph 搭的，比较难的就是 langgraph/deepagents 对 skill 的原生支持不大好。
各个业务方在 openclaw 时代搞了大量自己研究的策略/数据构造 skill，咋写的都有，一层套一层的还带状态，现在想直接接进来。
让把 skill 标准化成 MCP 吧，人觉得 skill 跑挺好，改造动力不足。