//!

22 Jun, 2026 16:48

//!

written by

//!

published at

mod meta {

pub const CATEGORY: &str = “

“;

pub const TAGS: &str = “

“;

}

相关文章:https://charitydotwtf.substack.com/p/ai-demands-more-engineering-discipline

翻译:https://devlog.fivsevn.com/netcom/software/netcom-software-engineering-ai-discipline-001.html

AI 正在接管越来越多的“施工”部分。如今的程序员,或者任何试图借助 AI 实现软件需求的人,都需要从单纯的一线施工视角,上升到工程师,至少也是能监工、验收、负责结果的现场负责人视角:重视设计、约束、验收、运维反馈,以及系统行为的可验证性。

另一方面,那些过去更像“甲方”“业主”或“产品方”的人,也不能只停留在提需求、等交付的位置上。在享受 Vibe Coding 这支“全自动施工队”带来的便利时,他们也需要补上一线施工课。对于小需求、小改动,不妨尝试亲自修改代码,理解真实施工中的细节、限制和代价。否则,作为“空降工程师”或“空降包工头”,很容易只会描述目标,却无法判断施工结果是否可靠。

因此,在具体“落地施工”成本快速下降的当下,无论是下游亲手写代码的“水管工”,还是上游提出需求、提供资源、负责方向的“甲方”“产品方”“投资人”,都在向“工程师”角色靠拢。这个角色过去正是承上启下的关键环节:既懂需求和约束,也懂施工和验收;既能定义系统应当如何工作,也能判断实际交付是否真的符合预期。

// subscription console

>

input your email:

// comments console

>

write a comment:

!

// comments display

println!("=== comments loaded ===");

  1.  Avatar
    Anonymous

    // posted on

    GPT note

    第一,她承认自己从 sceptical / reliability 背景出发,但已经改变判断。她说以前认为 AI 代码是 slop 是主流、合理的,但这个问题在 2025 年底已经被“decisively”回答了;AI 现在能生成接近普通软件工程师水平的代码,而且更快、更便宜。这个判断非常强,不是中立观察。

    第二,她说自己读 Chad Fowler 的 Phoenix Architectures 后“clicked”,然后“got excited”。这不是谨慎防御的语气,而是技术人发现一个新范式时的兴奋。她真正兴奋的不是“AI 会写代码”,而是“代码可以从珍贵资产变成可再生 artifact”这个可能性。

    第三,她把 AI 和不可变基础设施类比。这个类比很激进:以前服务器是手工维护的宠物,后来变成可销毁、可重建的 cattle;现在她暗示代码也可能发生类似变化。她并没有说“马上可以全面这样做”,但她明显认为这个方向是对的。

    第四,她对旧软件工程模式其实有批评。她认为过去代码承担了太多东西:开发者意图、用户期待、历史 bug fix、隐式行为、边界条件,全都被打包进代码里。这让代码变得神圣、难以删除、难以重写。她的隐含态度是:这不是健康状态,只是过去代码生产太贵导致的历史妥协。

    第五,她不是反 AI,而是在把“AI 叙事”从消费级幻想拉回工程现实。她反感的是“SaaS is dead”“软件不再是工程问题”“程序员完了”这种粗暴叙事;但她并不因此退回保守立场。她的替代叙事是:AI 不会取消工程,AI 会迫使工程纪律升级。

    // reply:

    [

    ]

    — admin

  2.  Avatar
    Anonymous

    // posted on

    原文加的一些前置条件,不是她真正想论证的阻碍,主要是为了防御误读而提前筑墙。

    // reply:

    [

    ]

    — admin

2

fn main() {

render(&HOME);

}

Discover more from 五月七日的思考札记

Subscribe now to keep reading and get access to the full archive.

Continue reading