人们谈论软件测试策略时，几乎总是从覆盖率讲起，而覆盖率恰恰是整个领域里信息量最低的一个数字。一个覆盖率达到九十的代码库，照样可能在最常被走到的路径上把缺陷送进生产环境，因为覆盖率衡量的是测试运行期间哪些代码行被执行过，而不是有没有针对这些行做出任何有意义的断言。 真正信任自己测试套件的团队，并不是覆盖率百分比最高的那一批。他们是这样一群人：当东西真的坏了，测试会红；其余时候，测试保持安静。这个性质比大多数人想象的更难用钱买到。 对任何一个测试都值得问的问题： 如果它失败了，我知道该怎么办吗？因为行为改变而失败的测试，会告诉你一些东西。因为某个实现细节挪了位置而失败的测试，只能告诉你有人做了重构。这样的失败积累到一定数量，团队就不再阅...
文章
在一个页面浏览所有文章。查找关于人工智能、编程、安全、基础设施与 Web 开发的教程、深度解读、指南与更新。
金融科技软件开发在报价和排期上，和普通软件开发没有任何区别，直到有人问出那句话：到底谁有资格持有这笔钱。从那一刻起，项目就不再是一道工程题，而变成一道带着工程成分的监管题，你脑中原本的时间表也不再成立。 技术很少是难点。搬运资金是一个已经解决的问题，市场上有成熟的服务商、有文档齐全的接口，还有第一天就能用起来的测试环境。真正拖长金融科技项目的，是牌照上的身份、面向审计要拿得出的留痕义务，以及好几个架构决定其实早已由持牌方替你做完了。 决定你时间表的问题： 你自己持牌，还是以代理身份挂在别人的牌照下运营，抑或完全避开受监管业务？这三个答案会产生长度完全不同的项目，而差距是用等待的月数衡量的，不是用开发的周数衡量的。在做任何范围规划之...
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 爬虫可以阻止你的内容被抓取消化，但同...
Cloudflare Queues 解决的是每个无服务器应用迟早都会撞上的那个问题：一个请求到达，触发了一段用户本不该等待的工作。发送确认邮件、给上传的图片改尺寸、把记录同步到第三方服务。这些活儿的共同点是：它们必须发生，但并不需要在用户按下按钮的那一刻发生。在传统服务器上，你把这类活儿交给一个后台工作进程就行了。可是在 Workers 上，请求处理完就结束，根本没有可以交出去的常驻进程。 常见的几种绕开办法，比看上去更糟。把工作放在请求里同步做完，等于让用户去等一个邮件服务商的响应。向另一个 Worker 发出请求却不等待它，只要发起方的调用先结束，这个任务就丢了。这两种做法都扛不住服务商的一次故障。 队列真正给你的是什么： 是持...
Cloudflare Hyperdrive 的存在，是为了解决一个非常具体、也毫不光鲜的问题：一个在 200 座城市里运行的 Worker，去和一座城市里的那一个 Postgres 数据库对话，会比同一条查询从紧挨着这台数据库的服务器发出更慢。不是慢一点点，而往往是慢上好几倍，而且这些原因和查询本身怎么写完全没有关系。 当一个无服务器应用显得迟钝时，人们的第一反应通常是怪查询规划器，或者再加一个索引。但在与某个区域数据库通信的 Workers 上，查询本身通常没有毛病。真正出问题的是连接。 Hyperdrive 真正修好的东西： 建立一次数据库连接的代价，而且这笔代价要在每一个请求上重新付一遍。一条 Postgres 连接在第一行数...
电商的 GEO 比内容型 GEO 范围更窄，而且在一个具体的地方反而更简单：一个要回答商品问题的助手，想要的是可以直接说出口、不必绕圈子的事实。价格、是否有货、尺寸、兼容清单、退货期限。这些要么以机器可读的形式存在于你的站点上，要么就不存在，而不存在的东西没法被引用。 所以这与其说是写作问题，不如说是数据问题。大部分工作落在商品 feed 和标记上，而不是落在销售文案上，这跟这个领域里其他所有议题的重心正好相反。 决定能否被采用的，是准确度而不是完整度。 一个系统说出了你的价格却说错了，它就产生了一个糟糕的答案，而避免糟糕答案最省钱的办法，就是不再使用不可靠的来源。过期的库存与价格数据是被剔除最快的一条路，而且和排名处罚不同，没有人...
没有人能用当年衡量搜索引擎优化的那套办法来衡量 GEO，原因不是工具不够用，而是结构本身变了。旧指标全都建立在一个前提上：会有人点击。当年值得知道排名，是因为排名可以预测流量，而流量可以预测收入。可是当答案不需要一次访问就被直接送到用户面前时，这条链条在第一环就断了，而它下游的每一个数字仍然照常上报，好像什么都没有发生。 危险的地方正在这里。排名看着正常。会话数看着还撑得住。仪表盘是绿色的，可你真正在意的那一块正在归零，而标准报表里没有任何一栏是为了把这件事告诉你而设计的。 要盯的信号是展示量在涨而点击量持平，而且必须按查询词逐条去看，不能只看整站汇总。 在汇总数字里它是隐形的，因为几个正常增长的页面就足以把它盖过去。在本站，...