Ai完全取代程序员框架（复杂软件）探索，半路开搞ai开发的中年人幻想
- 内容介绍
- 文章标签
- 相关推荐
啰嗦警告，我打字少，也没写过什么博客，想到什么写什么，而且还很啰嗦。
我在做软件销售之前，尝试着学了学写代码。那时候搞c嵌入式开发，网上的资料都是英文，然后还得去英文论坛发帖去请教一些问题，折磨的很。然后后来又开始搞售前售后什么的，最近几年彻底转了软件销售。
但我一直很讨厌写代码，感觉完全没有乐趣，做的东西也不知道有什么用，过程天天对着调试。有时候看着大厂那些动辄上十的程序员想着：也许他们比较厉害，乐趣也很大。就一直很佩服他们。
直到ai出现
我终于觉得有一些乐趣了，觉得是可以投身的事业。但是我感兴趣的，不是我终于可以快乐的写代码，而是我希望，世界上再也不要有这么多程序要写，我希望再也不要受到这种折磨，我再也不希望我要去羡慕那些很厉害的程序员，但真实接触下来却发现他们都只是些庸才。
这也许站在了很多论坛朋友们的对立面，抱歉
所以在用我的方法，慢慢的试着推进这件事，下面是我当前在尝试的一些初始想法和框架逻辑：
在我接触过的行业里面，有两个东西是逻辑严谨的，一个是写小说，一个是写代码。而且软件工程里其实文档是很重的，但一直被大家忽视，所以我想用文档来构建代码的逻辑。
建立文档抽象层，使用严谨的文档逻辑构建项目基础。我个人觉得这个过程有点像一个概率编译器，因为编译器是对语言进行确定化的二进制转码，但严谨文档到程序还是有非常多可选项的。
文档抽象层要定义重要逻辑、输入输出api、黑箱引用规则等等，这个在不断完善。
文档生成后1方面要生成代码，另2方面要生成检测器，使用ast等构建技术对代码逻辑是否符合文档进行严谨测试。文档迭代的审核机制也是必须的。
正在缓慢推进中，最近harness和spec火起来我不要脸的说一句，我感觉我似乎走的更前
网友解答：--【壹】--：
文档也是ai写的，只不过这种结构需要人类去搭建，过程是完全没有人类参与的
--【贰】--：
我感觉真正理想的是人来提出问题，ai想办法解决。
以前以为自己喜欢写代码，后面在用ai的过程中才发现其实自己也不是真的喜欢一行一行敲代码。而是享受解决问题的过程，代码只是其中一个工具。
最近就用cc、codex帮朋友vibe了几个离线小网页，给他们用得到好评，我就感觉很开心。
--【叁】--：
想法很好，路还很长，之前也有想做一句话实现项目开发，但实际上中间还有很多 AI 的不确定性，加上工具概念迭代太快，跟不上了
--【肆】--：
的确，工具和规范都要匹配当前的模型能力，但从另一个角度来说，从过去发现一些当时没用的东西，也许现在都能派上大用处
--【伍】--：
其实现在写文档也是告诉ai大方向然后让ai写最后自己审一下吧
--【陆】--：
实际上ai现在距离完全取代程序员仍然是有距离的，甚至于说是程序员的逻辑思维成就了现在的ai，如果ai完全取代程序员，那就不会有更多逻辑思维的输入了
--【柒】--：
可惜我朋友少
体会不到这种快乐了。少数几个还都是做生意的，都不碰电脑
--【捌】--：
做生意的不是更容易有需求吗？
比如从供货商那拿到清单时，怎么快速安排分配数据给下游；下游的每月的营业额怎么汇总，怎么和上游一起计算利润；员工的销量、任务完成数怎么快速计算奖金。
多了去了，只要问问他们有没有什么流程感觉很不方便，尤其是多系统数据整合，你都可以写小东西给他们用。
--【玖】--：
我不知道当年的从UML直接出代码，算不算是你说的这件事，因为如果要说严谨性的话，我觉得UML还是要比文档更严谨的，而且精练。可惜UML也没能兴起，在大厂圈子里推了一圈，小厂好像没几个人玩这东西的，尤其是后来敏捷出来之后，老板们嗨了，写个story就能出代码，而且还快，哈哈哈哈，这就是当初很多土老板对敏捷的看法。土老板对能提高生产力的东西都很感兴趣，哪怕内行看起来像天方夜谭，所以这也大概是你说的“庸才程序员”存在的原因吧，因为很多土老板只需要庸才。
--【拾】--：
image991×539 140 KB
--【拾壹】--：
全错，走那种纯文档开发的路子，最后又会有一个人跳出来说那为什么不让ai生成文档呢，我走在了你们之前。
--【拾贰】--：
感谢，这种工具迭代快的感觉我也有过，但我现在更认为慢慢来，想做做就好了，失败也只是人生而已
--【拾叁】--：
我倒是第一次听说这个软件实习生模式，
sczerg:最初的软件实习生模式，就是组长写文档和函数名称和注释，然后实习生写函数体，组合起来形成一个大软件。
感谢，我查过这个模式了，似乎能省不少时间。你说的对，我也不知道这种文档有没有价值，但我想试试
--【拾肆】--：
这个概念确实非常有帮助，有可能当初的这些软件工程实践都有可能拿出来用了，我仔细研究一些试试
--【拾伍】--：
最初的软件实习生模式，就是组长写文档和函数名称和注释，然后实习生写函数体，组合起来形成一个大软件。
但是现在的AI，都是深度思考做规划，很少一上手就开写的，也不知道文档驱动的开发，有没有实际价值。
最终还是落到AI的性能，代码写出来不正确，就算文档再好也没用。还是要看运气，不断摇奖，抽卡。
--【拾陆】--：
好萌
这个图感觉能让我快乐好久哈哈，这是用的什么？
--【拾柒】--：
大模型本身的能力最重要，再怎么文档化只能规矩AI的开发流程，但是写的代码好不好，取决于大模型基础能力。
--【拾捌】--：
的确，我都是等着别人来吐槽需要什么，不会主动去思考别人想要什么。还是我自己的问题，心思不在这上面
--【拾玖】--：
harness之类的概念很早就有了，只是模型太拉跨没法落地，后来claude为首的模型和agent效果起飞后才体系化地提出来
啰嗦警告，我打字少，也没写过什么博客，想到什么写什么，而且还很啰嗦。
我在做软件销售之前，尝试着学了学写代码。那时候搞c嵌入式开发，网上的资料都是英文，然后还得去英文论坛发帖去请教一些问题，折磨的很。然后后来又开始搞售前售后什么的，最近几年彻底转了软件销售。
但我一直很讨厌写代码，感觉完全没有乐趣，做的东西也不知道有什么用，过程天天对着调试。有时候看着大厂那些动辄上十的程序员想着：也许他们比较厉害，乐趣也很大。就一直很佩服他们。
直到ai出现
我终于觉得有一些乐趣了，觉得是可以投身的事业。但是我感兴趣的，不是我终于可以快乐的写代码，而是我希望，世界上再也不要有这么多程序要写，我希望再也不要受到这种折磨，我再也不希望我要去羡慕那些很厉害的程序员，但真实接触下来却发现他们都只是些庸才。
这也许站在了很多论坛朋友们的对立面，抱歉
所以在用我的方法，慢慢的试着推进这件事，下面是我当前在尝试的一些初始想法和框架逻辑：
在我接触过的行业里面，有两个东西是逻辑严谨的，一个是写小说，一个是写代码。而且软件工程里其实文档是很重的，但一直被大家忽视，所以我想用文档来构建代码的逻辑。
建立文档抽象层，使用严谨的文档逻辑构建项目基础。我个人觉得这个过程有点像一个概率编译器，因为编译器是对语言进行确定化的二进制转码，但严谨文档到程序还是有非常多可选项的。
文档抽象层要定义重要逻辑、输入输出api、黑箱引用规则等等，这个在不断完善。
文档生成后1方面要生成代码，另2方面要生成检测器，使用ast等构建技术对代码逻辑是否符合文档进行严谨测试。文档迭代的审核机制也是必须的。
正在缓慢推进中，最近harness和spec火起来我不要脸的说一句，我感觉我似乎走的更前
网友解答：--【壹】--：
文档也是ai写的，只不过这种结构需要人类去搭建，过程是完全没有人类参与的
--【贰】--：
我感觉真正理想的是人来提出问题，ai想办法解决。
以前以为自己喜欢写代码，后面在用ai的过程中才发现其实自己也不是真的喜欢一行一行敲代码。而是享受解决问题的过程，代码只是其中一个工具。
最近就用cc、codex帮朋友vibe了几个离线小网页，给他们用得到好评，我就感觉很开心。
--【叁】--：
想法很好，路还很长，之前也有想做一句话实现项目开发，但实际上中间还有很多 AI 的不确定性，加上工具概念迭代太快，跟不上了
--【肆】--：
的确，工具和规范都要匹配当前的模型能力，但从另一个角度来说，从过去发现一些当时没用的东西，也许现在都能派上大用处
--【伍】--：
其实现在写文档也是告诉ai大方向然后让ai写最后自己审一下吧
--【陆】--：
实际上ai现在距离完全取代程序员仍然是有距离的，甚至于说是程序员的逻辑思维成就了现在的ai，如果ai完全取代程序员，那就不会有更多逻辑思维的输入了
--【柒】--：
可惜我朋友少
体会不到这种快乐了。少数几个还都是做生意的，都不碰电脑
--【捌】--：
做生意的不是更容易有需求吗？
比如从供货商那拿到清单时，怎么快速安排分配数据给下游；下游的每月的营业额怎么汇总，怎么和上游一起计算利润；员工的销量、任务完成数怎么快速计算奖金。
多了去了，只要问问他们有没有什么流程感觉很不方便，尤其是多系统数据整合，你都可以写小东西给他们用。
--【玖】--：
我不知道当年的从UML直接出代码，算不算是你说的这件事，因为如果要说严谨性的话，我觉得UML还是要比文档更严谨的，而且精练。可惜UML也没能兴起，在大厂圈子里推了一圈，小厂好像没几个人玩这东西的，尤其是后来敏捷出来之后，老板们嗨了，写个story就能出代码，而且还快，哈哈哈哈，这就是当初很多土老板对敏捷的看法。土老板对能提高生产力的东西都很感兴趣，哪怕内行看起来像天方夜谭，所以这也大概是你说的“庸才程序员”存在的原因吧，因为很多土老板只需要庸才。
--【拾】--：
image991×539 140 KB
--【拾壹】--：
全错，走那种纯文档开发的路子，最后又会有一个人跳出来说那为什么不让ai生成文档呢，我走在了你们之前。
--【拾贰】--：
感谢，这种工具迭代快的感觉我也有过，但我现在更认为慢慢来，想做做就好了，失败也只是人生而已
--【拾叁】--：
我倒是第一次听说这个软件实习生模式，
sczerg:最初的软件实习生模式，就是组长写文档和函数名称和注释，然后实习生写函数体，组合起来形成一个大软件。
感谢，我查过这个模式了，似乎能省不少时间。你说的对，我也不知道这种文档有没有价值，但我想试试
--【拾肆】--：
这个概念确实非常有帮助，有可能当初的这些软件工程实践都有可能拿出来用了，我仔细研究一些试试
--【拾伍】--：
最初的软件实习生模式，就是组长写文档和函数名称和注释，然后实习生写函数体，组合起来形成一个大软件。
但是现在的AI，都是深度思考做规划，很少一上手就开写的，也不知道文档驱动的开发，有没有实际价值。
最终还是落到AI的性能，代码写出来不正确，就算文档再好也没用。还是要看运气，不断摇奖，抽卡。
--【拾陆】--：
好萌
这个图感觉能让我快乐好久哈哈，这是用的什么？
--【拾柒】--：
大模型本身的能力最重要，再怎么文档化只能规矩AI的开发流程，但是写的代码好不好，取决于大模型基础能力。
--【拾捌】--：
的确，我都是等着别人来吐槽需要什么，不会主动去思考别人想要什么。还是我自己的问题，心思不在这上面
--【拾玖】--：
harness之类的概念很早就有了，只是模型太拉跨没法落地，后来claude为首的模型和agent效果起飞后才体系化地提出来