可读性是可维护性，可维护性是责任与约束，也是支撑。
1 最终落到某个人身上时，他得负责。可读性为这个人能负责提供尽可能多前提。
2 目前AI需要人来驱动，岗位分工需要人来负责。

基于以上，
1 传统的可读性定义就要发生变化。可读性是“有利于、可支持人驱动AI”。
2 基于AI窗口尺寸，定义“模块”尺寸。模块的 fan-out，加起来的尺寸，在这个窗口尺寸内即可。

方向：
1 绝对不要加任何注释。代码已经是“代”意图+机器指令的码了，再加注释是“代代”码了。对AI是障碍。
人需要了解时，一个“模块”丢给AI总结即可。
2 不需要拆分函数，一个文件 8000行（假设加依赖，仍在AI的上下文窗口内），完成一个功能即可。single-page-app 思路。
3 建立更多更粗粒度接口（上面的模块），配套更多测试，发展多样化测试（UI暂时不行）。解决AI输出不可重复的问题。不像编译器。

感觉能做到的就是1。先行动起来。哈哈哈。2，3对AI都够呛。

【 在 hgoldfish 的大作中提到: 】
: 最近在我们团队内，几个小伙伴对 AI 有个争议。就是我们还要在乎 AI 生成的代码，面向碳基人类的可阅读性吗？
: 传统的软件工程要求有清晰的变量、高扇入、低依赖。每个函数要有合理的代码行数等等。但仔细考虑一下，这里都是在假定修改代码很难，需要人类多次阅读的基础上面设定的规矩。如今代码是 AI 写的，也是给 AI 读的。还需要这些规矩吗？
: Linus 说，现在的 LLM Agents 写代码，和他们当年从汇编升级到 C, Pascal 编译器其实差不多，都是让工具生成代码。而编译器发展到现在，也没人在乎编译器生成的汇编代码是否能够让人类阅读了对吧。
: ...................
--
修改:DoorWay FROM 61.185.186.*
FROM 61.185.186.*