What We Learned Building Our Own Site With Claude (Not the Generic “AI Changes Everything” Take)

我们用 Claude 构建网站后的心得（而非“AI 改变一切”的陈词滥调）

We use Anthropic’s Claude to help build and maintain this site — it’s the AI assistant answering questions in the corner of this page right now, and it’s also been in the room for the actual engineering work: bug fixes, new features, content, even internal tooling. That gives us a real answer to a question prospects ask a lot: does AI actually hold up on production work, or is it a demo trick? Here are three specific things we learned, not the generic “AI changes everything” take. 我们使用 Anthropic 的 Claude 来协助构建和维护本网站——它不仅是此时此刻在页面角落回答问题的 AI 助手，也深度参与了实际的工程工作：修复 Bug、开发新功能、撰写内容，甚至是构建内部工具。这让我们能够回答潜在客户经常提出的一个问题：AI 在生产环境中真的靠谱吗，还是仅仅是个演示噱头？以下是我们学到的三点具体经验，而非那种“AI 改变一切”的泛泛之谈。

1. AI is only as good as its willingness to verify, not guess

1. AI 的能力取决于它是否愿意验证，而非盲目猜测

A mobile layout bug came in: a section on the homepage was crowding the edge of the screen on phones. The obvious move is to read the CSS and reason about what should be wrong. That’s also how you miss the real bug. The actual cause was a legacy stylesheet with five overlapping @media breakpoints that aren’t mutually exclusive — a fix scoped to one breakpoint doesn’t override a conflicting rule at a wider breakpoint that’s still in effect at the same screen width. The only way to catch that reliably was live browser inspection at the actual viewport size — checking computed styles, not just reading the source and assuming. We treat that as a hard rule now: verify UI fixes in a real browser before calling them done, every time, no exceptions for “obvious” fixes. 我们遇到了一个移动端布局 Bug：主页上的某个板块在手机上挤到了屏幕边缘。最直观的做法是阅读 CSS 并推断哪里出了问题，但这恰恰是错过真正 Bug 的原因。实际原因是遗留样式表中存在五个重叠且非互斥的 @media 断点——针对一个断点进行的修复，无法覆盖在相同屏幕宽度下仍然生效的、更宽断点中的冲突规则。唯一可靠的排查方法是在实际视口尺寸下进行实时浏览器检查——查看计算后的样式，而不是仅仅阅读源代码并进行假设。我们现在将其视为一条铁律：在宣布完成之前，必须在真实浏览器中验证 UI 修复，每次都如此，即使是“显而易见”的修复也不例外。

2. The failure modes of the tool matter as much as its capabilities

2. 工具的失效模式与它的能力同样重要

Generating a branded social media graphic sounds simple — a photo, a logo, some text. Doing it programmatically (rather than by hand in a design tool) means moving image data through several systems: downloading a photo, encoding it, handing it to a script, exporting the result. One early attempt corrupted an image silently — no error, just a slightly-wrong file that “worked” until you checked the byte count against the source. The fix wasn’t a smarter AI, it was a different process: move binary data file-to-file through the shell instead of retyping it, and verify file sizes instead of trusting that “no error” means “correct.” That’s an engineering discipline problem, not a model-quality problem, and it’s the kind of thing you only learn by actually shipping things, not by reading about AI coding in the abstract. 生成一张带有品牌标识的社交媒体图片听起来很简单——一张照片、一个 Logo、一些文字。但以编程方式（而非在设计工具中手动）完成它，意味着要让图像数据经过多个系统：下载照片、编码、交给脚本、导出结果。在早期的一次尝试中，图像被静默损坏了——没有报错，只是文件略有偏差，直到你将字节数与源文件进行对比时才发现。解决办法不是使用更聪明的 AI，而是改变流程：通过 Shell 在文件间移动二进制数据，而不是重新输入，并验证文件大小，而不是盲目相信“无报错”就等于“正确”。这是一个工程规范问题，而非模型质量问题，这是只有在实际交付产品时才能学到的经验，而不是通过抽象地阅读 AI 编程文章能获得的。

3. Genuinely obscure technical depth is where it gets interesting

3. 真正晦涩的技术深度才是最有趣的地方

Building a branded PowerPoint template meant understanding the difference between a .potx template and a regular .pptx file — which, it turns out, has nothing to do with the file extension. It’s a single content-type declaration buried in the file’s internal XML (presentationml.template.main+xml vs presentationml.presentation.main+xml). Get that wrong and PowerPoint silently treats your template as a regular presentation. That’s not a “write me a poem” task. It’s the kind of specific, unglamorous technical detail that separates AI-assisted work that actually ships from AI-assisted work that looks good in a demo and falls apart on contact with a real file format. 构建一个品牌 PowerPoint 模板意味着要理解 .potx 模板和普通 .pptx 文件之间的区别——事实证明，这与文件扩展名无关。它取决于埋藏在文件内部 XML 中的一个内容类型声明（presentationml.template.main+xml 与 presentationml.presentation.main+xml）。如果搞错了，PowerPoint 会静默地将你的模板视为普通演示文稿。这可不是“给我写首诗”那种任务。这正是那种具体、枯燥但关键的技术细节，它区分了能够真正交付的 AI 辅助工作，与那些在演示中看起来不错、一接触真实文件格式就崩溃的 AI 辅助工作。

The honest takeaway

真诚的总结

None of this replaces engineering judgment — it accelerates it, if the process around it is disciplined: verify instead of assume, know your tools’ actual failure modes, and don’t shy away from the unglamorous technical details. That’s the same standard we hold any senior engineer to, human or AI-assisted. 这一切都无法取代工程判断力——它只是加速了这一过程，前提是相关的流程必须严谨：验证而非假设，了解工具的实际失效模式，并且不要回避那些枯燥的技术细节。无论对于人类还是 AI 辅助的工程师，我们都坚持同样的标准。