现在新概念叫「Specification Engineering」
编写一份严谨、可版本化、可执行的 Spec
这份 Spec 将作为唯一的「真理之源」（source of truth），最终编译成文档、评估、
模型行为，乃至代码本身。
在 AI 时代，Spec 能真正做到「一次编写，处处运行」。
一份书写的 Spec， 核心价值在于，它能够让所有人类（产品、研发、法务、安全等）
在一个共同的目标集上对齐。

代码本身就是 Spec 的一种 「有损投影」（lossy projection）。

一份足够强大的 Spec，在 AI 的辅助下，可以「编译」成优质的 TypeScript、Rust、
服务器、客户端、文档、教程、博客文章，甚至播客。

rust可能就慢慢的类似旧时代的汇编, 大部分人用不上, 创造价值时不需要

【 在 tianyalaike 的大作中提到: 】
--
修改:ABCDEFGHJKLM FROM 103.135.163.*
FROM 103.135.163.*

代码的压缩率太低, 还得写大量注释
spec写到AI认为足够准确,能接受的程度, 压缩率高的多,
而且PM、法务、市场人员都能看懂, 不是只有工程师能看懂

【 在 chunhui 的大作中提到: 】
如果spec能写到这个标准，准确,完善的程度，那还不如直接写代码。
【 在 ABCDEFGHJKLM 的大作中提到: 】
: 现在新概念叫「Specification Engineering」
: 编写一份严谨、可版本化、可执行的 Spec
: 这份 Spec 将作为唯一的「真理之源」（source of truth），最终编译成文档、评估、
: ...................
--
修改:ABCDEFGHJKLM FROM 103.135.163.*
FROM 103.135.163.*

编程语言终究还是要发展到更高层次抽象的, 类比SQL统一数据库领域, 可能也有很多低
级优化无法SQL描述的, 但还是SQL为主,可能加各种扩展; 各种jvm clr虚拟机, 也优化到非常极端的程度了, 没法让普通程序员选择, 虚拟机替你决定怎么做更好

类似编程语言源码更重要, 但编译产物也是要管理的, 因为编译器本身也可能有bug,

spec就是以后的源码, AI就是编译器, 产生的各种语言代码就是编译产物,

如果有模糊的地方AI应该自行选择, 选择不了的跟人类沟通, 就是几选一的事不至于必
须用 代码/汇编/机器码才能描述

【 在 chunhui 的大作中提到: 】
我的意思是说，你用自然语言，永远都无法写到代码级的准确完备程度。永远都有模糊地带。不可能做到一个spec，到处运行的程度。最终被执行的还是代码，出错了，到底是改代码还是改spec？但是spec描述的不准确。最后聚焦到这个模糊点上之后发现，spec无法描述。只能用代码来说明。。。
或者你坚持用自然语言描述这个模糊点的话，会发现需要用非常复杂冗长的文字，人还是看不懂。还不如看代码。

就好像数学公式一样，如果用自然语言方便描述公式，那就不需要发明数学公式了。
【 在 ABCDEFGHJKLM 的大作中提到: 】
: 代码的压缩率太低, 还得写大量注释
: spec写到AI认为足够准确,能接受的程度, 压缩率高的多,
: 而且PM、法务、市场人员都能看懂, 不是只有工程师能看懂
: ...................
--
修改:ABCDEFGHJKLM FROM 103.135.163.*
FROM 103.135.163.*