Neward & Associates
Ted Neward 的博客，关于软件架构、编程语言与开发者生态的深度思考。
评论
点赞
收藏研究：LLM 默认使用什么语言？
当不指定编程语言时，LLM 默认用什么写代码？本文复现了 Chad Fowler 的经典实验，在本地运行 Qwen、Gemma、GLM 等模型进行测试。结果：Python 是绝对默认项，与云端模型一致。最大发现是 glm-4.7-flash 在 48 个任务中全部失败——输出超长、自我推翻、无法收敛。作者详细记录了适配过程、各模型表现差异，并开放了可复用的 tasks.yaml 测试框架供社区继续贡献。有具体数据、有踩坑记录、有可复用的工具，适合想了解 LLM 实际编程偏好的技术读者。
关于新互联网时代的一些随想
除非你年纪尚小，还不具备饮酒的资格； 或者你曾住在群山之巅、远离林线的简陋木屋中，否则你大概或多或少都还记得“互联网时代”。 这一时期也被称为“网络时代”（与紧随其后的“点对点时代”并称），那时互联网尚属新生事物， 边界尚未被充分探索，而人们的盲目信任也被推向了极致。 当然，我之所以要提起这段历史，是因为当前人工智能批评界普遍认为，我们正站在“后泡沫”人工智能时代的边缘。 也就是说，“人工智能泡...
关于编程代理与IDE，我的一些零散思考
一位有25年经验的资深开发者用编程向导(Wizard)、VB拖拽式开发和IDE崛起三次历史技术争议为参照，剖析当前AI编程代理引发的行业焦虑。他明确表态：编程代理不会消失但远未成熟，真正改变格局的时刻是当代理被深度嵌入IDE时。文中穿插亲身经历的Borland OWL与MFC之争、vi/emacs命令行派与IDE派的论战等鲜活细节，有明确立场、历史旁证和具体技术判断，不是空泛的趋势评论，而是带着经验与幽默的个人观察。
我对编码智能体与IDE的一些随想
一位25年经验的老程序员将当前编码Agent引发的焦虑，类比为历史上三次开发者「被工具取代」的恐慌：代码生成向导、VB拖拽式开发、IDE取代命令行工具。作者亲身经历过Borland C++ OWL与MFC的阵营之争，认为Agent不会消失也不会完全取代IDE——真正的方向是Agent深度嵌入IDE（如直接操控调试器）。他建议开发者自行实验找到与Agent的相处之道，并隔空喊话JetBrains等厂商抓住窗口期。文章有个人经验、有历史纵深、有鲜明观点和真实态度，不是空洞趋势文或机构通稿。
关于初级开发者，我的一些想法
作者用论证者分析、历史类比（70年代计算器进课堂引发的恐慌）和逻辑分析三重框架，有力反驳"AI让初级开发者过时"的流行论调。核心洞见：宣扬初级开发者消亡论的人（AI公司CTO、工具卖家）大多能从这一预言自我实现中获利。作者亲历70-80年代计算器争议——当时教育界同样称计算器会"毁掉一代人的数学能力"，但今天会计师并未被计算器取代，而是用它辅助专业判断，前提是必须先理解底层原理。类比到AI编码工具：初级开发者仍需要从头学会编程思维和犯错、调试、理解代码的能力，否则维护AI生成代码的人从何而来？最后给出务实建议：企业应主动通过内部学徒项目培养初级开发者，构建技能金字塔（1资深+2中级+3初级），避免依赖昂贵的外部招聘。文章还引用Bruce Tate关于"AI让代码不再犯错，新人反而失去学手艺的机会"的深刻观察，以及a16z的同类分析报告。全文立场鲜明，有人味、有经验、有可操作建议，值得讨论。
关于数据隐私，我的一些不成熟想法
核心看点：你的文档、邮件、上传文件都可能被服务商拿去训练AI模型，而你面对"全有或全无"的隐私条款几乎没有真正的选择权。作者从Gmail读取用户邮件训练AI的旧事切入，指出大模型时代服务商对数据的利用已从"提取统计数字存入数据库"升级为"理解文本并训练新模型"。以邮件为例——对现代人而言邮件已如水电网般是基础生活设施，数百万人的唯一稳定邮箱就是Gmail——谈何真正退出？作者进而质问那些上传到OCR等SaaS服务的机密文档，服务商的隐私政策是否允许其将文档用于训练其他模型或测试套件？他建议企业CISO立即审计所有服务商，要求金融/法律/医疗等敏感行业必须获得书面声明，承诺数据不被用于训练AI。核心观点：法律上或许合规，但用户感知和信任比法律风险更重要——换掉一个供应商比打一场官司容易得多。当公众舆论转向"用我的数据训练你的模型"时，转向会非常猛烈迅速，现在就该提前行动。
关于数据隐私的一些想法
随着LLM崛起，企业上传给第三方SaaS服务商的文档可能被用于训练AI模型。作者以Google十年前扫描Gmail邮件内容被法庭认定为"用户应合理预期"的先例切入，指出当前隐私政策实质是"全有或全无"的强制同意——而邮件等在线服务已近乎现代生活必需品，用户并无真正选择权。核心警告：你的OCR、文档处理等SaaS服务商可能在利用上传的机密数据训练模型，而企业法律团队往往未仔细审查隐私条款。作者明确立场：问题不在合法性（隐私条款很可能已授权此类使用），而在客户感知——换掉一个供应商比打一场法律官司容易得多。建议CISO立即启动审计，要求所有服务商签署不将上传数据用于AI训练的具约束力声明，并约定未来任何相关使用须事先明确征得同意。结论是公众对"拿我的数据训练模型"的反噬会又快又猛，未提前防范的公司将遭遇严重PR危机。
研究：角色提示词的真实影响
一位软件工程师亲自设计实验，系统验证 LLM 角色提示词（role prompt）是否真的改变输出。实验分三阶段：先用不同角色（helpful / unhelpful / smart-but-arrogant / dumb-but-eager）问同一问题，发现角色主要改变措辞和语气，事实内容基本一致；再用不同资历等级（初级/高级/首席工程师、律师、医生、甚至 Guido van Rossum）让模型写斐波那契代码，发现一旦角色包含"软件工程师"，等级修饰词几乎不影响答案——所有角色都产出正确的迭代解法。Ruby 和 C# 版本同样如此。作者附完整 Python 代码、原始输出和 GitHub 仓库，鼓励读者自行复现。文风有鲜明的个人声音和幽默感，不是机构通稿，不是营销文，是真正动手做的经验分享。
我想我所想：编程智能体与Visual FoxPro的时代呼应
这篇博客将90年代4GL开发工具（FoxPro、Visual Basic）与当今LLM编程智能体做了精妙类比：AI编程智能体可能让个人开发者重获当年"一人搞定全部"的单兵作战能力。作者以亲历的C++开发者与VB开发者之间的"高尔夫球杆"之争为引子，指出智能体生成代码与VB的拖拽式开发有相似之处——便利但隐藏底层细节。但他也敏锐指出关键区别：LLM的非确定性输出使"稳定生成相同代码"难以成为常态，且编程语言本身对智能体效果影响显著（如动态语言在Claude Code上表现更好）。文章最有价值的部分是对企业IT未来走向的三种推演：创新中心（放大个人开发者影响力）、成本中心（裁撤冗余人员）、文艺复兴（类比佛罗伦萨的繁荣，将智能体视为"执行润滑剂"，预示创意应用大爆发）。全文有个人观察、有技术史脉络、有前瞻判断、有幽默脚注，是难得有人味有深度的技术随笔。
裁员心理剖析：当职业成为身份，失去工作意味着什么
当身边不断有人被裁，为什么我们反应如此强烈？作者从LinkedIn一则帖子出发，深入剖析了一个常被忽视的根源：在西方社会，我们从孩提时代就被训练用学校、年级、职业来定义自己——陌生人见面第一句"你是做什么的"就暴露了这种身份与工作的深度捆绑。裁员不只是一份工作的失去，而是对一个人自我认知的直击。作者结合自己三年前的三年"非自愿休假"经历，提出了关键建议：把自我认同从工作中抽离出来，重新建立在爱好、家庭、个人特质之上。你不是你的公司logo，你的价值远大于你的职位。这不是空洞的鸡汤，而是有切身经验支撑的真诚反思，文字有温度、有情绪、有实在的观察，值得每个经历过或担心裁员的人读一读。
我认为本地部署的LLM比云端服务更好
作者以亲身经历和鲜明立场，力挺本地部署LLM而非云端方案。文章从分布式系统谬误（以2026年Anthropic宕机事件为例）、AI公司经济泡沫（引用Ed Zitron的分析并直言泡沫必然破裂）、数据隐私隐忧（SaaS卖数据前车之鉴）、以及自建技术栈的学习价值四个维度展开。不仅有Ollama配置等实操细节，还讨论了Anthropic封禁OpenClaw等最新动态。核心论点是：依赖云端AI等于押注于一个脆弱且商业模式不可持续的系统，本地部署才是抗风险、保隐私、长本事的选择。文风幽默、有个人态度、有具体论据，是一篇观点驱动而非营销导向的优质技术随笔。
我思我想：为什么我偏爱本地部署的开源大模型
在公司内部待上一段时间时，我曾提到自己想尝试一款特定的工具，只不过打算使用本地托管的大型语言模型， 而非云端托管的模型。对方的回应基本上就是：“LULZ，你真想这么做？ ”不仅让我对这番话感到有些意外，更让我意识到，自己内心深处其实迫切地想要把原因说清楚——不过， 这种表达方式更适合写成一篇博客文章，而不是发在 Slack 上。 （这是我系列博客文章中的一部分，我会大声思考、畅谈那些“我自以为在...
《构建调试器》书评
一篇有很强个人声音和人味的技术书评。作者 Ted Neward 拿到 No Starch Press 寄来的《Building a Debugger》样书，从自己二十年来的信念——"开发者必须掌握比日常工作低一层的能力"——切入，坦言此前对调试器的理解只停留在"知道它能做什么"，从未真正动手构建过。这本书用 C++17 手把手教读者从零构建 x64 原生调试器 sdb，从项目结构、进程附加、断点设置到远程调试，一章一个主题。作者边读边动手，遇到 CMake 版本差异和系统依赖也如实记录下来。书评不是枯燥的内容摘要，而是带着鲜明观点的阅读体验分享：赞它的务实（第一章直接开干、不铺垫概念），也对第二章"14页讲完编译与计算机架构"的跳跃性提出客观警告。最后落到"买、读、改造"的号召，并畅想了理解调试器底层机制后能打开的工程想象力。全文有立场、有踩坑、有推荐逻辑，是一篇典型的优秀个人技术博客书评。
我对"触碰代码"这件事的思考
资深程序员Ted Neward用自己的真实实验和会议辩论，有力反驳了"AI编码代理终将让开发者不再直接触碰代码"的主流观点。他在VSLive!大会上与同行激烈争论后，亲自用Claude+OpenSpec编写井字棋游戏——两次惨败：代码无法编译、关键功能缺失、窗口都不显示、AI自信满满地撒谎说"全都实现了"。他深入剖析LLM的概率性本质（非确定性输出），指出即便只有0.01%的错误率，在万行级以上的真实项目中也会累积到不可接受。核心论点：开发者永远需要读写代码的能力，编码代理有用但人类必须在流程中，所谓的"零接触代码"在工程上不成立。文章有亲身踩坑记录、有概率计算、有立场、有幽默感，不是空泛趋势分析，而是一篇真正的技术随笔和讨论入口。
我思我想……「颠覆」
一个软件老兵的自白：当行业惯用的「颠覆」利刃终于指向自身时是什么感受。作者在Nutrient搭建开发者关系部门之际，直面LLM编程助手带来的集体焦虑——裁员恐慌、技能过时、职业安全感崩塌。不兜售解决方案，不粉饰太平，而是以坦诚的个人视角，借用Alan Greenspan「创造性破坏」理论以及农业机械化、马匹被汽车替代、电力普及等历史类比，论述这场风暴的必然性与两面性。更难得的是，作者承认软件行业三十年来对出租车、制造业、前台接待等行业的颠覆，如今因果循环落到自己头上。一篇有温度、有自省、有历史纵深感的行业随笔，适合每一位对AI时代职业前景感到不安的人读一读。
2026年科技预测
Ted Neward 照例发布年度科技预测系列，先以亲身经历盘点2025年10胜9负的预言成绩，再对2026年做出12项预判。核心看点：AI 炒作将加速而非降温，OpenAI 可能在承诺兑现上陷入困境，"氛围编程"（vibe coding）将撞墙崩溃，而 AI 编程助手会持续升温。作者以二十年的行业观察串联个人求职、出书、演讲等经历，犀利抨击 VC 驱动的"下一个大事件"循环，质疑 Sam Altman 的承诺可信度。对代码本质有深刻洞察——"不是说代码能写出来就够了，关键是你是否真正理解问题。"文风幽默真诚，观点鲜明有力，信息密度高，适合与同行讨论、反驳或继续深挖。
DevRel 活动模式一书正式出版：从模式语言到统一方法
作者自 2023 年起为开发者关系（DevRel）活动构建了一套"模式语言"，如今与三位合著者将其打磨成书，由 Apress 于 2025 年底出版。全书用 39 个聚焦模式，覆盖 DevRel、DX 与社区管理的基础策略，每个模式基于真实经验、面向可扩展性设计。作者特别强调，度量指标是 DevRel 的"无声杀手"，团队在书中花大力气为每个活动模式梳理了可用的评估指标。文章坦承模式集未必完备，欢迎从业者补充或质疑——因为模式的本意不是即食解决方案，而是推动讨论、提供共同语言。适合单人布道者、小团队或大规模 DevRel 领导者阅读参考。
Linguis：让开发者用母语写代码的可插拔语法编程语言实验
Linguis 是一个实验性编程语言项目，核心理念是让同一套 AST（抽象语法树）支持多套可替换的关键词语法，使非英语母语者能用自己熟悉的语言写代码。作者 Ted Neward 早年访问比利时看到法语版 BASIC 后深受触动，质疑为什么 2025 年的编程世界仍然默认以英语为前提。他用 Python 实现了 parser 层与 AST 解耦的原型，目前已跑通英语、法语甚至 Pig Latin 三种语法集，并公开了完整仓库邀请社区贡献。文章包含具体的技术实现（Python AST 对象、compile 调用流程）、真实的开发日志和迭代过程（从自定义 AST 到原生 Python AST），也有明确的讨论入口（多语法 round-trip 是否可能？编程语言应该继续以英语为中心吗？）。不是通稿或营销，是真正有个人经验、有动手实践、能激发讨论的优质技术博客。
为什么写作对技术人员至关重要
当ChatGPT能秒出各种文章，技术人员还值不值得花时间练写作？作者用亚马逊内部变革给出了有力答案：贝索斯2004年废除PPT，改用六页纸书面叙述作为会议材料，因为幻灯片导致决策浅薄、遗漏细节、容易被口才误导。写作不止是沟通——它强迫你把模糊的思维模型具象化，暴露隐藏的错误假设（就像程序员向同事解释bug时突然自己找到答案）。写作也是个人品牌：清晰、精准的文字能跨越性格内向传播，让观点脱离作者本身站得住。作者引用了大量一手来源——亚马逊前高管的《Working Backwards》、Paul Graham、叔本华论两种作者——并指出ChatGPT缺乏对世界本体的理解，永远无法写出"确定而清晰"的实质内容。对于想晋升的技术人来说，写作可能是投资回报率最高的单一技能。
“球员兼教练”的角色陷阱
核心看点：一个人同时承担团队管理和独立贡献者（IC）双重职责的"Player/Coach"角色，本质上是个陷阱。作者以亲身经历指出，这种角色注定会偏离平衡——新手管理者往往会过度投入IC工作（写代码、做演讲），导致辅导团队、1:1沟通、招聘等管理职责被严重挤占，最终团队流失、绩效下滑、角色瓦解。核心观点：你不能同时拥有两个优先级第一的目标。文章提供了一个实操框架——前6个月100%做IC熟悉业务，接着6个月集中招聘并逐步移交IC任务，团队满员后彻底转型为全职管理者。还列出了三个"红旗信号"：招聘启动时间承诺超过6个月、团队最终规模不超过2人、公司要求先证明自己再给编制——这些几乎注定失败。有亲身经历、有具体方法、有可复用的判断标准，适合带团队或正在转型的工程师/技术管理者阅读。