首先，我必须要说，你搞错了。
照你的说法，软件是由“人类规划，AI 代工”的。
你将 AI 视为一台速度极快的打字机，认为软件是从无到有“写”出来的。
但事实上，软件的本质并非被创造，而是被“发现”。
米开朗基罗（Michelangelo）曾说过一句至理名言：
“Every block of stone has a statue inside it and it is the task of
the sculptor to discover it.”
（每块石头里都有一尊雕像，雕塑家的任务就是去把它敲出来。）
这句话不仅是雕塑的最高境界，更是现代 AI 生成技术的核心底层逻辑。
我们看看当今主导图像生成的 Stable Diffusion 技术，它的运作原理是什么？
是从一张充满随机噪声的画布开始，透过 AI 一步一步地“去噪（Denoising）”，
将不符合提示词（Prompt）的噪声剔除，最终“浮现”出那张完美的图像。
AI 不是在画画，AI 是在充满无限可能的像素噪声中，把那张本来就存在的完美照片
给“雕刻”出来。如果图像生成是如此，软件工程为何例外？
请仔细深思这个事实：在每一台电脑的硬盘与内存的二进制排列组合中，
早就已经存在着无数个“完美的软件”。
无论是一个无懈可击的影音编辑软件，还是一个颠覆世界的作业系统，
它们的原始码早已潜伏在你硬盘中的 0 与 1 无限矩阵里，宛如藏在巨石中的大卫像。
我们根本不需要“写”程式，我们只需要把“不是这套完美系统的程式码”给敲掉。
这就是人类与 AI 合作的终极型态。
在这过程中，甚至不需要你去规划，因为你是人，人所规划出来的软件绝对不是完美的
你只需要去感受，就像感受神性一样去感受品味，
让 AI 剥去你硬盘中覆蓋那完美软件的 0 与 1。
在你感受变强烈的时候，告诉 AI 继续通往直前。
在觉得变弱的时候，叫 AI 试着其它方向看看。
虽然过程中 SDD, TDD, 与 harness 都不可少，但最重要的还是你的感受。
※ 引述《gigayaya (gigayaya)》之铭言：
: [前言]
: 花了好多时间终于努力在连假打完这篇文，大约有4500字，预估阅读时间约30分钟
: 原本有想说要不要拆成多篇，后来为了一致性决定还是放在一篇文章内，不好意思XD
: 每次想说还可以再拖一下的时候就发现有新资讯出来在更新我的观念，觉得再不发出来一
: 直放在我的电脑内我会永远都发不出来XD
: —正文—
: [序]
: 自从工程师们发现AI可以很好地帮助工程师们coding后，工程师们便开始了一系列的‘使
: 用AI来开发’的技术探索。
: 从Prompt engineering开始研究如何设计prompt而得到品质更高的code。到发现光有
: prompt不够，于是开始Context engineering的研究如何将AI需要的资讯在对的时机提供
: 给AI。到最近的 Harness engineering，工程师意识到让 AI 全速冲刺反而容易失败，没
: 有防护措施的高速行驶容易因为一小点的偏差而将错误无限放大。于是开始为 AI 加上工
: 具、规则、检查...等等，让它能跑得更久、更稳，从一次性的代码生成器，变成能执行
: 长期复杂任务的 agent。
: 随着每次技术以及模型底层能力的迭代，工程师们deliver result的速度越来越快，品质
: 越来越高，但我相信不少工程师们心中应该都冒出同一个疑问：
: 我们一直迭代‘使用AI开发程式’技术的终点是什么？
: 在最近几个月阅读许多资讯以及自己的实际经验中我得出一个对于这件事情的答案，想藉
: 由这篇文章和大家分享。
: 如果你对于这件事情的终点没有想像的话，或许你可以参考看看。如果你心目中的终点和
: 我不一样的话，也欢迎分享你的想法多互相讨论，让我们更往前进一步。
: 最后，因为这里是Soft_job版，所以我讨论的前提都是在software development这个非常
: 局限的框架底下，希望大家读文章的时候不要无限上升到人类与AI的方方面面上XD
: —
: [我们用AI来开发程式的最终目标是什么？]
: 我觉得我们之所以要用这么多的AI工程技巧在开发程式上，最终目的是为了要：‘设法降
: 低从想法到产品落地之间的成本’
: 想像未来的一个场景：
: 你是Meta Messenger团队的一员，有一天下午你躺在沙发上对这个产品有一个新的想法：
: ‘在一个chat中的textfield左边的+号里面有一个新的白板icon，点开会打开一个小白板
: ，使用者可以在小白板上用笔迹画一张图并且送出’。于是你拿出你的手机，在Jira网页
: 上开一个新的ticket，内容是描述你对这个新功能的想法以及规格。开完后你发现某个
: AI bot已经pick这张ticket开始实作。三小时后你收到一个PR request请你验收这个功能
: 的实作，你review了一下看到所有test都pass所以按下了approve按钮，15分钟后世界上
: 所有的使用者的Messenger都有这个白板功能了。
: 假设这件事情未来真的会发生，那会怎么发生？我们目前距离那里还差多远？
: —
: [为什么我们想要达成最终目标？]
: 自从2025年AI coding的能力提升到开始可以应用在产品级生产环境之后，我们迎来了‘
: coding民主化’的时代。意思是‘AI能力进化到任何一般人都可以很简单地使用AI生产出
: code以及program来完成他们的需求’
: 这个能力在以前对于‘一般人’来说是一个很有技术门槛的事情，通常来说你需要去上个
: 课，不论是大学四年本科的学习或是资策会的半年冲刺班甚至是上youtube看一段教学影
: 片，对一般人来说‘coding一个程式去做一件事情’都是要花成本去学习的任务
: 但现在随着AI模型的能力上升以及工具的普及，任何人都可以下载Claude Code，开启一
: 个session，对着AI使用自然语言跟AI描述你的需求，AI就会生产一段可以完成这个任务
: 的code给你。
: 这代表着未来‘code/程式’将会到处都是，任何人不论是会计师还是律师还是ooxx，任
: 何有电脑的人他都可以自己产生他自己需要的程式，就像智慧型手机在现在几乎人手一机
: 一样非常普遍而不是稀缺资源。
: 那在这个‘任何人都可以生产程式’的情况下‘什么程式’才有真正的稀缺价值呢？我觉
: 得是‘拥有更好更能满足使用者’的程式会变得更有价值。
: 例如：当市面上有一大堆相同功能的记帐软件之后，一个有真正创新且独特使用者品味的
: 程式将会更脱颖而出，因为人们用了许多平庸的程式之后会更加能够体会‘好’的东西是
: 为什么‘好’
: 但是因为生产程式码很快，假设今天大家的程式都是N，你想到了一个很好的新功能将你
: 的程式往前推进到N+1取得领先位置，过了10天后你的对手也跟进新功能变为N+1，大家又
: 回到相同的起点你的领先优势只维持10天。你必须在那10天对手还没追上你时想出下一个
: 新功能，在对手N+1追上你的时候赶快推出N+2保持更好的产品状态继续取得领先，这样你
: 才能在这市场中一直占据领先地位，最后取得商业上的成功。
: 所以在我的想像中，未来的软件领域比拼的是‘想法/idea’的竞争。当每间公司每个app
: 都有能力做到同样的功能拥有同一个起跑线的时候，想出下一个‘使用者更想要的功能’
: 的那个app就可以脱颖而出
: （当然品质的要求没有下降，还是跟目前一样甚至更高）
: 于是为了达成这个目标，我们软件工程师在公司中的任务就是：‘打造出能够越快将想法
: 递交给使用者的程式及架构’。这个目标的scope已经不是只有传统软件工程的范围了，
: 借助AI达成这个目标已经是一个必备项目了。所以做为软件工程师你除了熟练原本的code
: 架构外也要熟练/了解各种AI工程技巧来帮助你达成目标
: 现在‘比拼idea’的方式是：比谁更快把idea做出来
: 未来‘比拼idea’的方式是：比谁更快把‘更好’的idea做出来
: —-
: [如何达成这个目标？]
: 首先我想我们应该都有一个共识就是AI产出code的速度比人类手敲键盘快非常多，所以想
: 要快速产出大量程式码的最好方式就是指挥AI去写，但是在现实中有很多问题需要克服：
: A. 你下的prompt是否足够准确让AI产出你真正想要的东西(prompt engineering)
: B. 你必须要给予AI足够的背景知识去完成这个任务(context engineering)
: C. 你必须确保AI产出的code品质被验证满足标准(harness engineering)
: … etc.
: 其中还有许多困难，但简单来说就是将现在的‘工程师完成一个新功能’这件事情在“满
: 足标准”的前提下：‘快速化’、‘自动化’
: 将原本可能一个sprint(2 weeks)才能完成的任务在几小时内完成
: 或许未来的codebase中可能有50%或是更高比例的file是给AI工程用的而不是产品本身
: 另外这件事情不只是模型能力提升或是AI使用技巧的迭代就可以简单达成的，你还需要原
: 本软件工程师的经验以及能力，将整个codebase进行一次全面的转型
: 例如：
: A.要让你的application可以快速地新增功能并且不破坏其他原本旧有的功能，你的架构
: 在模组化以及抽象化的取舍会更重要
: B. 要能够随时deliver新功能给使用者的一种方式是借由热更新，但能够热更新在设计产
: 品架构之初就必须考虑设计好否则后期大改架构的成本很高
: C. 实作code的时候很常遇到trade-off的问题，像是两个选择都可以但没有哪一个一定比
: 较好的情况。这时候你必须做出决定给出AI指引某一条路并且你知道为什么这是对产品比
: 较好的选择
: … etc.
: A和B两点背后都可以转换成类似design pattern的问题，而我们都知道这类问题通常都没
: 有一个永远的最佳答案，每个专案每个产品在乎的事情都不一样，只有根据你们公司策略
: 、领导决策、产品定位、团队规模、系统效能...等等才能选出最适合的答案。而这也是
: 软件工程师体现价值的地方。
: 但其实你也可以说一旦我们对于最终目标有共识大家都去追逐这个目标之后，AI就可以自
: 动对所有的application产生符合这个目标的最佳code。但这边我有一个理论是当大家都
: 最佳化后就代表大家也都同样平凡，到那时候就会有一个人类从无到有想出下一个新目标
: 做出差异化来提高价值，于是我们永远都会有下一个目标可以追逐
: 我觉得在目前的现实世界中，Claude Code是最接近这个例子的program
: Claude Code可以一天迭代1,2个新版本递交新功能，抢占最新的技术前沿，使得后面的追
: 赶者追得很辛苦不容易赶上，进而维持Claude Code在CLI工具上的领先地位
: 而Claude Code也可以借由频繁的更新迭代收集更多最新的使用者数据，来让他们统计使
: 用者数据来决定下一次版本迭代的目标，让整个飞轮高速地旋转起来
: —
: [测试/验证的重要性]
: 在这个最终目标的情境下，目前如果我们想要更快的递交新想法，整个瓶颈会卡在测试这
: 一个步骤。
: 因为(在不透过人类去使用的前提下)我们是通过测试去观测我们产品，换句话说，测试的
: 品质会大大地影响我们如何理解我们的产品以及品质。
: 例如：我们的产品是一个简单计算机app，结果我们的测试一直都没有‘验证加号＋’的
: 运算逻辑，那这样子就算我们能够大量快速地deliver许多新功能并且每次所有test都绿
: 灯pass又有什么意义呢？
: 所以，在未来的时代我觉得‘测试’以及‘验证’的重要性可能会越来越重要，并且这是
: 之后每个不同的公司不同的产品不同的team出现差异化的地方，之后的测试验收手段可能
: 会被视为重要资产而被高度保护，并且每个不同domain的测试方法会越来越专业化复杂度
: 越来越高。
: 就像现在大家会看到许多公司都会分享他们是如何做出最新的产品以及如何使用最新的技
: 巧，但是我从2023开始几乎没看到有人分享更高级的测试验收工程技巧。我们的产品级测
: 试验证手法自从playwright mcp后就没有什么工程技巧上的重大突破了，如果要达成梦想
: 中的最终目标我感觉现在‘测试’的速度落后开发的速度很多。
: 我记得几年前我看过一个例子：
: 一间公司分享他们如何运用prompt engineering做出一个超级智慧的客服机器人并且顾客
: 满意度达到9成多。他们大方分享他们最后使用的1000多行的强大prompt出来，但是那份
: prompt高度客制化，如果你要使用他们的工程经验来实作你自己的prompt在你的产品上就
: 会发现他们在生产迭代prompt时的‘测试验收’这一步骤轻描淡写的用一句：
: ‘我们每次迭代后会用我们准备好的测试集来评分’来描述却没有进一步的解释，但这一
: 步才是整个工程的关键。
: 如何准备你的测试集？需要多少笔资料才够？需要收集多少错误处理的情况？如何评分？
: 如何决定迭代策略？没有解决这些问题的话就算你手上有那份1000行的精美prompt也没
: 办法复制出同样高品质的客服机器人在你的domain上。
: 如果你曾经‘完全用AI’去生产你们产品‘全部的测试’，你就会发现目前AI在这部分完
: 全不行，他常常产出一些莫名其妙的test case或是不存在的scenario（因为transformer
: 天生的机制就是会一直接话下去），需要人类去介入做review。在我看来我们在‘测试’
: 这个领域还需要许多工程技巧的进步去追上生产程式码进步的速度。
: 当然你也可以主张最后这个部分随着模型能力提升后AI也可以取代/超越人类，但是我也
: 想提一个我一直认为的观点：
: 只要是给人使用的产品，那最终只有人类可以定义它的价值，以及被产品满足
: 这部分我觉得是AI无法取代的
: —
: [未来什么事情是重要的？]
: 首先，我觉得CS知识本身还是很重要，因为最终AI写出的code组成的program还是奠基在
: computer science上，所以为了达成前面提到的最终目标，扎实的CS功力是不可缺的。
: AI工程技巧也同样重要，就像前面所说的，如果你还是只能用手敲键盘写code的话，那你
: 会追不上未来产品需要迭代的速度。所以‘使用AI的知识以及使用AI工程技巧产生code’
: 也是软件工程师的必备技能
: 除此之外最近也有个词被反复提及：品味。
: 在coding这个level来说的话，品味指的是：你知道当下应该采取什么是最好的选择、你知
: 道为什么采取A策略而不是B策略可以更好地达成你的目标...等等，简单来说是要有能判断
: code好坏的能力（这实在好难用文字说明...）
: End
: —
: [推荐阅读的参考资料]
: 1.程式码全让 AI 写，工程师只看测试就够了吗？
: https://www.youtube.com/watch?v=_yKtlczRFKk
: 这是一个更极端的策略：黑箱开发。意思是把你的codebase当作一个黑箱，只专注在他
: 能提供什么功能上，把codebase当作抛弃式的东西。当你觉得继续使用现有的codebase成
: 本太高的话就可以直接抛弃他再重新产生一个。
: 虽然我不推崇将codebase当作黑箱，我觉得工程师还是要对codebase有一定的掌握度，但
: 是这个影片所叙述的开发流程还是有许多值得参考的地方。
: 2."Software Fundamentals Matter More Than Ever" — Matt Pocock
: https://www.youtube.com/watch?v=v4F1gFy-hqg
: 这个影片中主讲者分享了软件工程跟AI工程要如何结合，我觉得从12:30开始关于‘Good
: Codebase Are Easy To Test’这部分非常有启发性
: 3.How Anthropic’s product team moves faster than anyone else | Cat Wu (Head
: of Product, Claude Code)
: https://www.youtube.com/watch?v=PplmzlgE0kg
: 这应该是最近最热门的影片之一了，Claude Code的Head of Product Cat Wu的一个访谈
: 影片。其中谈到对于未来软件的想像以及产品团队如何运作，推荐完整看完。
: 4.Andrej Karpathy: From Vibe Coding to Agentic Engineering
: https://www.youtube.com/watch?v=96jN2OCOfLs
: 最近最热门的影片之二，我觉得整个演讲对于过去现在以及未来的软件工程都有一个清晰
: 的描述，推荐完整看完。
: 5.【漫士】AI时代，我们真的会失业吗？怎么办？
: https://www.youtube.com/watch?v=vOIkUSYfUMo
: 这部影片的作者从数学系博士的角度出发解释了目前AI的原理以及局限性，如果你不是那
: 么清楚现在的AI底层是什么的话推荐看看，对于未来的描述也蛮有启发性的（尤其是创意
: 的部分）。
: