文章

软件维护成本，就是那个把一个成功项目在十八个月之后变成一场难堪谈话的数字。开发阶段有预算、有审批、也如期交付了。可上线之后会发生什么，被一句「支持服务」轻轻带过，然后配上一个有人凭感觉给出的金额，而那个金额几乎每一次都太小。 原因出在结构上，不是谁不上心。开发有一个可以定价的范围。维护没有范围，因为决定它的是还没有发生的事情：某个依赖库爆出漏洞，某个供应商改掉了自己的接口，某个用户碰上了当初谁都没想到的情形。 人人都在引用的经验法则是每年按开发成本的 15 到 20 个百分点计算，而它之所以危险，恰恰是因为它离正确答案不远。 它对的次数多到让人放心，错的时候又总是朝同一个方向错：它低估了缺陷集中冒出来的第一年，而在有合规义务或者外部...

技术尽职调查不是一场代码质量比赛，而为它做准备的团队，往往把时间花在了完全不重要的地方。没有哪个买家是为了给你的抽象层打分才来收购公司的。买方想弄清楚的只有两件事：持有这套系统要花多少钱，以及在钱易手之后，事情可能糟糕到什么程度。 这个视角的转换很重要，因为它会改变你应该优先修哪里。丑陋但能跑、团队看得懂、可以安全修改的代码，只是一条轻微的发现。相反，写得优雅却只有一个人看得懂的代码，是一条严重的发现，而真正会让价格发生变化的，恰恰是后者。 所有问题背后的那个问题： 如果创始工程师在交割后的第二周离职，这套系统还能继续运行、并且继续被修改吗？几乎每一条压低报价的发现，都是对这个问题的具体回答。知识集中在一个人的脑子里、没有文档的部署...

数据库性能的排查工作，通常从有人提议换一台更大的实例开始，又通常以这样一个发现结束：每次加载页面时，有一条查询都在对 400 万行做顺序扫描。瓶颈从来不是硬件，瓶颈是执行计划。 这个模式重复得足够稳定，值得当作默认假设写下来。当应用很慢而数据库又很忙时，原因几乎总是少数几条具体的查询，而不是整体容量不足；把机器换大，只能把问题掩盖到表再次长大的那一刻为止。 动手改之前，先量。 凭猜测去优化一条查询，正是团队花掉整整一周添加索引、结果写入变慢而读取一点没快的原因。任何数据库都能告诉你哪些语句消耗的总时间最多。从那里开始，修掉排在最前面的那条，然后再量一次。这样反复两三轮，事故通常就结束了。 数据库性能始于找出那条查询总时间比最坏单次更...

实体SEO的出发点是一个大多数优化建议至今仍然忽略的事实：搜索引擎早就不再匹配字符串了。它们匹配的是事物。一个页面得到什么分数，并不取决于它是否包含某个词组，而取决于系统是否相信这个页面讲的是词组背后的那个概念，以及系统对这个概念到底是什么有多大把握。 这个区别决定了重复关键词究竟对你有帮助，还是完全不起作用。在匹配字符串的系统里，重复是一种信号。在匹配实体的系统里，重复只是噪声，真正能推动结果的，是机器能不能识别出你是什么。 判断你是否作为实体存在的测试： 搜索你的公司名称，看看在没有人追问的情况下，搜索引擎主动给出了关于你的哪些信息。如果它只返回首页，别的什么都没有，那么你只是一串它能找到的字符。如果它返回了描述、所在地、类别以...

人们谈论软件测试策略时，几乎总是从覆盖率讲起，而覆盖率恰恰是整个领域里信息量最低的一个数字。一个覆盖率达到九十的代码库，照样可能在最常被走到的路径上把缺陷送进生产环境，因为覆盖率衡量的是测试运行期间哪些代码行被执行过，而不是有没有针对这些行做出任何有意义的断言。 真正信任自己测试套件的团队，并不是覆盖率百分比最高的那一批。他们是这样一群人：当东西真的坏了，测试会红；其余时候，测试保持安静。这个性质比大多数人想象的更难用钱买到。 对任何一个测试都值得问的问题： 如果它失败了，我知道该怎么办吗？因为行为改变而失败的测试，会告诉你一些东西。因为某个实现细节挪了位置而失败的测试，只能告诉你有人做了重构。这样的失败积累到一定数量，团队就不再阅...

金融科技软件开发在报价和排期上，和普通软件开发没有任何区别，直到有人问出那句话：到底谁有资格持有这笔钱。从那一刻起，项目就不再是一道工程题，而变成一道带着工程成分的监管题，你脑中原本的时间表也不再成立。 技术很少是难点。搬运资金是一个已经解决的问题，市场上有成熟的服务商、有文档齐全的接口，还有第一天就能用起来的测试环境。真正拖长金融科技项目的，是牌照上的身份、面向审计要拿得出的留痕义务，以及好几个架构决定其实早已由持牌方替你做完了。 决定你时间表的问题： 你自己持牌，还是以代理身份挂在别人的牌照下运营，抑或完全避开受监管业务？这三个答案会产生长度完全不同的项目，而差距是用等待的月数衡量的，不是用开发的周数衡量的。在做任何范围规划之...

MVP 软件开发出问题的地方是范围会议，不是开发过程本身。有人说出「最小可行产品」这几个字，大家点头认可，接着送来的功能清单里却写着用户账号、后台管理面板、计费、通知、仪表板，还有一个移动应用。那不是最小可行产品。那是一个完整的产品，而它花掉的时间会是你心里那个数字的三倍。 真正造成损害的词是「可行」。多数团队把它读成「好到可以卖给所有人」，可它的本意是「刚好够用来判断到底有没有人想要这个东西」。 最省钱的范围测试： 对每一项功能，问问自己会因为答案不同而做出什么不一样的事。如果一项功能改变不了任何决定，它就不属于 MVP。后台管理面板不会告诉你人们是否想要这个产品；它只会告诉你，等人们想要之后，这个产品会更好管理。把它放到第二步再...

有排名却从不被引用，是把搜索引擎优化做对了、却眼看着它什么都没带来的那种非常具体的挫败感。排名来了。展示次数在涨。点击却没有跟上，而且把标题标签改写多少遍都不会有变化。 这不是你优化上的失败。这是当结果页不再是一份链接清单、而变成一个答案时必然发生的事。而且它现在已是常态，不是一个值得拿去诊断的异常。 我们自己的数据，来自 Search Console，统计口径是截至 2026 年 8 月初的 28 天： 本站有 531 个查询词排在前十位，带来 28,847 次展示，却只换到 161 次点击。这就是 0.56% 的点击率，而第四到第十位在历史上通常能拿到 2% 到 8%。这 531 个查询词里，有 452 个一次点击都没有产生。 ...

llms.txt 现在到底有没有用？诚实的答案是：在可测量的范围内几乎没有用，而那些告诉你这个文件对 AI 可见性至关重要的人，通常是在向你推销东西。一边这样说，一边又建议你发布一份，这个立场并不舒服。所以这篇文章先把数字摆出来，然后再解释这条建议本身。 文件本身是个合理的主意。它是放在网站根目录下的一份 markdown 索引，告诉语言模型你发布了什么、内容在哪里，就像 robots.txt 告诉爬虫哪些内容可以抓取一样。想法没有问题。问题出在它原本要服务的那些公司身上，它们几乎没有采用。提出一份规范，和真正出现读取它的一方，完全是两回事。 服务器日志真正显示的情况： Ahrefs 对 137,000 个域名的分析发现，2026 ...

要不要屏蔽 AI 爬虫，通常被摆成一个技术问题，但它并不是。屏蔽本身只是几行配置，在 robots.txt 里加几条规则，或者在网络层打开一条规则，十分钟就能做完。真正难的是决定你到底想不想这么做，而这个决定完全属于生意范畴：你是在两件事之间做取舍，一边是保护内容不被拿去训练模型，另一边是继续出现在人们如今用来替代搜索结果列表的那些答案里。 网上大部分建议都是先站队，然后只替自己那一边说话。诚实的说法是另一种：正确答案随商业模式而变。一家靠页面浏览量吃饭的媒体，和一家靠询盘吃饭的服务公司，本来就应该得出完全相反的结论。如果两者的答案一样，那才是真的出了问题。 这笔交易一句话就能说完： 屏蔽 AI 爬虫可以阻止你的内容被抓取消化，但同...