Here’s What AI-Native Looks Like这就是“原生 AI”的样子

Want to come back later? Save this to readplace.com.想稍后再看？保存到 readplace.com。

I remember the first software I developed in an actual company. It was circa 2006 when I implemented my website for my first client. It used iframes and crazy colors. When I showed the prototype to the client they unexpectedly said they had “given up” on building a website.我还记得我在一家真正的公司开发的第一个软件。那大约是在 2006 年，当时我为我的第一个客户实现了他们的网站。它使用了 iframe 和极其夸张的配色。当我向客户展示原型时，他们出人意料地说他们已经“放弃”构建网站了。

That’s how bad it was. 😅可见它当时有多烂。😅

Almost half a million karma on Reddit and thousands of submissions on HackerNews later, I decided to create a SaaS for my hand-made 10 year-old read-later system so everyone could use it too. I called it readplace.com.在 Reddit 上积累了近 50 万点数，并在 HackerNews 上提交了数千次内容后，我决定为我那用了 10 年的手工“稍后阅读”系统创建一个 SaaS，让大家也能使用。我把它命名为 readplace.com。

Here are the first commits: https://github.com/Readplace/readplace.com/commits/main/?since=2026-02-28&until=2026-02-28以下是最初的提交记录：https://github.com/Readplace/readplace.com/commits/main/?since=2026-02-28&until=2026-02-28

I’ve been using assisted AI for coding since early 2023, but 2026 is when everything changed and I started using it full-time on Readplace. At the time of writing this, readplace.com has more than 3000 commits.我从 2023 年初就开始使用 AI 辅助编程，但 2026 年一切都改变了，我开始在 Readplace 上全职使用它。在撰写本文时，readplace.com 已经拥有超过 3000 次提交。

So yes I fully jumped on the AI bandwagon.所以，是的，我完全加入了 AI 的阵营。

But… why??? You sloppy *****!但是……为什么？？？你这个草率的家伙！

Creating a platform like this is not an easy feat, and I’m talking only about the engineering part. Most companies budget multiple feature teams at A$1M/year each just to achieve baseline parity. Alternatively, you can go the other way, use the Startup mindset and differentiate from competition, on a bet the big players will take longer to pivot to what you’re doing than your ability to convince a VC to give you a few millions for something you can’t do by yourself.创建一个这样的平台绝非易事，而且我仅仅是指工程部分。大多数公司会为每个功能团队拨出每年 100 万澳元的预算，仅仅是为了达到基本的对等水平。或者，你可以另辟蹊径，运用初创公司的思维方式并与竞争对手进行差异化竞争，赌的是大玩家转向你所做的事情所需的时间，要长于你向风投说服他们为你提供几百万资金来完成你自己做不到的事情的能力。

The core problem here is that any basic reading tool requires significant development effort just to achieve a baseline. It’s almost like a commodity nowadays. Until you can say “and this is what I use for filtering articles that’s different from everybody else” you need to build the whole read-it-later and reader infrastructure.这里的核心问题是，任何基础阅读工具都需要大量的开发工作才能达到基准线。如今这几乎成了大路货。除非你能说“这就是我用来过滤文章的方法，它与众不同”，否则你就得构建整个“稍后阅读”和阅读器基础设施。

Good luck… that is, if you're still living in the past!祝你好运……前提是你还活在过去！

I still use my local system until I can fully migrate to Readplace, but my local system is dumb as f***. However, it was built from my real use cases and experience, not speculation from a founder that managed to convince some VC to give them money so they can shoot in all directions in the hope they can get enough hits before they meet their maker.在我能完全迁移到 Readplace 之前，我仍在使用我的本地系统，但我的本地系统笨得要死。不过，它是根据我的真实用例和经验构建的，而不是来自那些设法说服风投给钱、然后为了在倒闭前尽可能多地获得成功而四处乱撞的创始人的臆测。

How my local system works? Oh glad you asked!我的本地系统是如何工作的？很高兴你问了！

Well… quite simple honestly (and that’s why it took 10 years to be where it is):嗯……说实话很简单（这就是为什么它花了 10 年时间才达到现在的程度）：

1. I receive emails from many of my GMail address aliases to my main GMail inbox (I have a legacy Google Workspace lifetime free account), then tag them with the “tbf” filter which means “to be filtered” so I know which ones are true emails and which ones are reading content.我将许多 GMail 地址别名的邮件接收到我的主 GMail 收件箱（我有一个传统的 Google Workspace 终身免费账户），然后用“tbf”过滤器标记它们，意思是“待过滤”，这样我就知道哪些是真正的邮件，哪些是阅读内容。
2. Then I spin up the “read-gmail-links” project that runs a query using GMail API with “is:unread label:tbf” on all emails, it crawls all links from every email to their final redirect and creates a UI that I can click, summarise the content based on my local preferences using Claude, and then give me a filtered list I can read and decide what to share and what not.然后，我启动“read-gmail-links”项目，它使用 GMail API 对所有邮件运行“is:unread label:tbf”查询，它会抓取每封邮件中的所有链接直到最终重定向，并创建一个我可以点击的 UI，使用 Claude 根据我的本地偏好总结内容，然后给我一个过滤后的列表，我可以阅读并决定分享什么，不分享什么。
3. After I decide what to share, I manually mark that email as read, it’s a manual copy/paste from the UI to my email with the label “share-to-community”.在我决定分享什么之后，我会手动将该邮件标记为已读，这是一个从 UI 到我的电子邮件的手动复制/粘贴过程，并加上“share-to-community”标签。
4. Then I manually run another command called “npm run start:add times=100” from “update-submissions-from-gmail” project that sends all those “is:unread label:share-to-community” emails to a dynamoDB table called “ALL_LINKS” in a big JSON array and marks them as read.然后，我手动运行另一个名为“npm run start:add times=100”的命令，该命令来自“update-submissions-from-gmail”项目，它将所有那些“is:unread label:share-to-community”的邮件发送到 DynamoDB 表“ALL_LINKS”中的一个大型 JSON 数组中，并将它们标记为已读。
5. That’s all for the reading. Later I have another UI (“links-automator”) that can read those and provide a dropdown with communities to select (HN, linkedin, /r/<subreddits>) + summary (which I may have edited) so I can remember what that was all about. Sharing that summary is the top 1 reason I’ve been banned from most of the subreddits I used to post sporadically in these 10 years.这就是阅读的全部过程。稍后我有另一个 UI（“links-automator”），它可以读取这些内容并提供一个下拉菜单来选择社区（HN、LinkedIn、/r/<subreddits>）+ 摘要（我可能已经编辑过），这样我就能记得那是什么内容了。分享那个摘要是我在这 10 年里被我偶尔发帖的大多数子版块封禁的首要原因。

Press enter or click to view image in full size按回车键或点击以查看全尺寸图片

Press enter or click to view image in full size

The first version of this system didn’t even use DynamoDB, it was a submissions.json file in Dropbox 🤣🤣🤣这个系统的第一个版本甚至没有使用 DynamoDB，它只是 Dropbox 里的一个 submissions.json 文件 🤣🤣🤣

Then came readplace.com.然后 readplace.com 诞生了。

So yeah in February I jumped on the bandwagon and got a number of Claude 20x subscriptions (now I got some Codex also). With my knowledge of AWS and coding infrastructure + testing and stability guard rails here’s what I managed to achieve in 7 months:所以，是的，二月份我加入了阵营，并购买了多个 Claude 20x 订阅（现在我也用了一些 Codex）。凭借我对 AWS 和编码基础设施的了解，加上测试和稳定性护栏，以下是我在 7 个月内取得的成就：

• THE Web Crawler for Reader View: Every fetch tries three transports, the last one carrying a real Chrome TLS fingerprint, then retries as an honestly declared bot, then goes again through a residential proxy through KYC verified BrightData tunnel. Tweets come in via oembed, Apple News stories get rebuilt from Apple’s own compressed document format, and seven sites have hand-written rescue rules because they otherwise save empty. If a site still wins, the reader offers to capture the page with your own logged-in browser instead.用于阅读视图的 Web 爬虫：每次抓取都会尝试三种传输方式，最后一种携带真实的 Chrome TLS 指纹，然后以诚实声明的机器人身份重试，接着通过 KYC 验证的 BrightData 隧道通过住宅代理再次尝试。推文通过 oembed 接入，Apple News 报道从苹果自有的压缩文档格式重建，还有七个网站有手写的救援规则，否则它们保存的内容会是空的。如果某个网站仍然无法抓取，阅读器会提供通过你自己的登录浏览器捕获页面的选项。
• Three canaries hit production every morning: 20 of the most hostile URLs on the web (NYTimes, LinkedIn, X, Apple News, arXiv, five PDFs) saved and parsed end to end through the live stack, plus nightly sweeps for links that failed or are still spinning. A red one opens a ticket, and the rule I wrote down is fix the crawler, never delete the URL to go green.每天早上有三个金丝雀测试进入生产环境：20 个网络上最难抓取的 URL（NYTimes、LinkedIn、X、Apple News、arXiv、五个 PDF）通过实时堆栈进行端到端保存和解析，外加夜间对失败或仍在处理中的链接进行扫描。红色的测试会打开一个工单，我写下的规则是修复爬虫，绝不为了通过测试而删除 URL。
• Scanned PDFs parsed as text: Readplace rasterises at 300 DPI, OCR up to 300 pages in parallel, one model pass to clean each page, a second to diff the whole document against the original, a third to turn it into semantic HTML. Fixtures cover 15 writing systems, and a scan where only 27 of 31 pages survive still renders, with the gaps marked.扫描版 PDF 解析为文本：Readplace 以 300 DPI 对 PDF 进行栅格化，并行 OCR 最多 300 页，第一轮模型处理用于清理每一页，第二轮用于将整个文档与原始文档进行差异比对，第三轮将其转化为语义 HTML。固定装置涵盖 15 种书写系统，即使扫描件中 31 页只有 27 页存活，它仍然可以渲染，并标记出缺失的部分。
• Readplace has its own OAuth 2.1 server: Consent screen, dynamic client registration, PKCE, discovery documents, 180-day refresh tokens rotated on every use. Twelve MCP tools sit on top, so ChatGPT or Claude can work your reading list with no manual API key required.Readplace 拥有自己的 OAuth 2.1 服务器：同意屏幕、动态客户端注册、PKCE、发现文档、每次使用时轮换的 180 天刷新令牌。顶部有 12 个 MCP 工具，因此 ChatGPT 或 Claude 无需手动 API 密钥即可操作你的阅读列表。
• Infra Using Pulumi IaC: 52 Lambdas in production, 71 queues with a dead-letter queue in front of every consumer, 24 DynamoDB tables, 41 alarms generated by the shared component so the 52nd Lambda is monitored by default, and 16 infrastructure stacks across two isolated AWS accounts (staging and prod). No click-ops anywhere, and staging has to pass before prod deploys.使用 Pulumi IaC 的基础设施：生产环境中有 52 个 Lambda 函数，71 个队列（每个消费者前都有一个死信队列），24 个 DynamoDB 表，由共享组件生成的 41 个警报，因此第 52 个 Lambda 默认受到监控，以及跨两个独立 AWS 账户（预发布和生产）的 16 个基础设施堆栈。没有任何点击式操作，预发布环境必须通过测试才能部署到生产环境。
• Tests: Around 13,000 tests across TypeScript, Swift and Kotlin — More test code than product code, 100% coverage enforced on 38 of 40 packages, 296 committed UI test screenshots with pixel baselines including greyscale e-ink at e-reader size, and 7 UI actions carrying millisecond budgets measured across 20 separate CI machines that block the deploy when one is breached.测试：TypeScript、Swift 和 Kotlin 共有约 13,000 个测试——测试代码比产品代码多，40 个包中有 38 个强制执行 100% 覆盖率，296 个已提交的 UI 测试截图，包含像素基准（包括电子阅读器尺寸的灰度电子墨水屏），以及 7 个 UI 操作在 20 台独立 CI 机器上测量毫秒级预算，一旦超出即阻止部署。
• The reading app itself: The card appears the instant you save and fills in behind you, a TL;DR streams into the reader for everyone, a panel tells you what you already read on this subject, and when you finish it picks the next unread thing out of your own library and says why it's related. Seven lists, EPUB export, server-rendered, no React.阅读应用本身：卡片在你保存的瞬间出现并填入内容，TL;DR（太长不看）摘要流式传输到阅读器供所有人查看，面板会告诉你关于这个主题你已经读过的内容，当你读完时，它会从你的库中挑选下一篇未读文章，并说明它为何相关。七个列表，EPUB 导出，服务器端渲染，不使用 React。
• Clients: A Chrome extension, a signed Firefox build, an iPhone app on the share sheet of every other app, right-click a link you never opened, one shortcut to swallow every tab in the window, and your own @read.place email address where a model keeps the articles and skip the ads and unsubscribe links. Uploading a Pocket export with no account: untick the rubbish, sign in at the last step, and up to 2,000 links land with your ticks intact.客户端：Chrome 扩展、签名的 Firefox 构建版本、可以在任何其他应用的共享菜单中使用的 iPhone 应用、右键点击你从未打开过的链接、一键吞掉窗口中的所有标签页，以及你自己的 @read.place 电子邮件地址，模型会保留文章并跳过广告和退订链接。在没有账户的情况下上传 Pocket 导出文件：取消勾选垃圾内容，在最后一步登录，最多 2,000 个链接会带着你的勾选状态导入。
• AI in my CI, not just my editor: 6 Claude workflows (code review, auto-applying review feedback, CI-failure fixing, conflict fixing) with more than 50,000 runs between them, plus a 30B vision model on a Mac in my office that stares at UI frames from CI for the broken layouts a pixel diff can’t see.CI 中的 AI，不仅仅是在编辑器中：6 个 Claude 工作流（代码审查、自动应用审查反馈、CI 失败修复、冲突修复），总运行次数超过 50,000 次，外加办公室 Mac 上运行的 30B 视觉模型，它会盯着 CI 的 UI 帧，寻找像素差异无法发现的损坏布局。

I made the project Open Source so you can see how I do it: https://github.com/Readplace/readplace.com我将该项目开源了，这样你可以看到我是如何做到的：https://github.com/Readplace/readplace.com

Here are the “DevOps” metrics:以下是“DevOps”指标：

• 99.9% uptime (CloudWatch, Feb to Sep, insert your real number)99.9% 正常运行时间（CloudWatch，2 月至 9 月，填入你的真实数字）
• No outage so far. Bugs happened, none took the system down or hit all users.到目前为止没有停机。出现过 Bug，但没有导致系统瘫痪或影响所有用户。
• Commits go straight to production in ~1–10m (sometimes 20m when it invalidates the nx cache).提交内容在约 1-10 分钟内直接进入生产环境（当 nx 缓存失效时有时需要 20 分钟）。

There have been hundreds of production deployments in 7 months. The Actions history in the repo is public, count them yourself. Oh, and did I tell you? I’m the only employee of the company. Also, I spent less than A$5k (Not U$5k, AUD 5k, do the math).7 个月内进行了数百次生产部署。仓库中的 Actions 历史记录是公开的，你自己数数吧。哦，我告诉过你吗？我是这家公司唯一的员工。而且，我花费不到 5000 澳元（不是 5000 美元，是 5000 澳元，自己算算）。

No fancy agent system. No fancy SaaS that promises to simulate employees. Just me, a CLI, and my brain.没有花哨的代理系统。没有承诺模拟员工的花哨 SaaS。只有我、一个命令行界面和我的大脑。

So how the hell do you use AI?那么，你到底是怎么使用 AI 的？

The best way to explain using the output of my /insights command:最好的解释方式是使用我的 /insights 命令的输出：

The loop I run every time我每次运行的循环

1. Ground it in evidence1. 基于证据

Start from a plan file, a production log, an error-funnel PDF, or a categorized pile of prod errors — never from intuition. The brief is outcome-shaped and tightly scoped.从计划文件、生产日志、错误漏斗 PDF 或分类的生产错误堆栈开始——绝不凭直觉。任务简报必须是结果导向的，且范围界定严格。

2. Implement — but don’t commit2. 实现——但不要提交

An explicit gate: implement this plan without committing. The work runs deep and multi-file (29-, 54-, 56-file changes) while you stay out of its way.一个明确的门槛：实现这个计划但不要提交。工作涉及深度和多文件（29、54、56 个文件的更改），而你只需置身事外。

3. Review the diff, correct surgically3. 审查差异，进行外科手术式的修正

I audit the result and fix the one wrong detail precisely — a radio button that should be a dropdown, queues > 0 that should be > 1, identity coupled to a display label, the reserved word "tier".我审计结果并精确修复那个错误的细节——应该用下拉菜单的单选按钮、应该大于 1 而不是大于 0 的队列、与显示标签耦合的身份、保留字“tier”。

4. Demand proof, not claims4. 要求证明，而不是断言

Before I accept it: screenshots, emulator/simulator pixel diffs, mutation-verified tests, a green workspace gate — and proof that any red check is a pre-existing flake, not your regression.在我接受之前：截图、模拟器/仿真器的像素差异、变异验证测试、绿色工作区门槛——并证明任何红色检查都是预先存在的波动，而不是你的回归错误。

5. Ship to production, then confirm5. 发布到生产环境，然后确认

The one order — commit and push it all — then watch CI to green, verify the deploy on staging and prod, and file follow-ups. The session ends at "verified live," not "code works."唯一的命令——提交并推送所有内容——然后观察 CI 变为绿色，验证预发布和生产环境的部署，并提交后续跟进。会话结束于“验证上线”，而不是“代码能跑”。

Operating principles操作原则

Delegate big, interrupt rarely大规模授权，少打断

Low messages per session against enormous autonomous Bash volume. I define the boundary and audit the result — you don’t micromanage the route. Often several sessions run at once.相对于巨大的自主 Bash 量，每个会话的消息量很少。我定义边界并审计结果——你不需要微观管理路径。通常同时运行多个会话。

Falsification over assertion证伪优于断言

I distrust unverified claims and push back hard: a “passing” check that was a misread piped exit code, a wrong “+19.9%” measurement, a greyscale-contrast claim — all retracted only after I pressed.我不信任未经证实的声明并坚决反击：一个被误读为管道退出代码的“通过”检查、错误的“+19.9%”测量、灰度对比度声明——所有这些都是在我坚持要求后才撤回的。

Say it plainly直言不讳

I tolerate long silent execution but not evasive conclusions. When an answer hedged with “both, in different places,” I demanded a straight yes/no before accepting it.我能容忍长时间的静默执行，但不能容忍闪烁其词的结论。当一个答案用“两者都有，在不同地方”来敷衍时，我要求在接受之前给出一个明确的是/否。

Always the “why”永远询问“为什么”

I ask for the business case, cost annotations, and RCA alongside the change — one whole session was an evidence-backed TypeScript adoption case, reframed until the data supported it.我要求在变更的同时提供商业案例、成本注释和根本原因分析（RCA）——有一个完整的会话是关于有证据支持的 TypeScript 采用案例，经过重构直到数据支持它为止。

Delete decisively果断删除

Removal is first-class, fully-verified work: share-expiry stripped across 54 files, the feature=audio toggle across 12 — mapped, swept, and shipped green like any feature.移除是第一类、经过充分验证的工作：跨 54 个文件剥离共享过期功能，跨 12 个文件移除 feature=audio 开关——像任何功能一样进行映射、扫描并以绿色状态发布。

Codify what repeats将重复的工作编码

Heavy Skills + Workflows and multi-agent triage/deep-read pipelines — I encode a procedure once instead of re-explaining it, and treat implementation as cheap and reversible.繁重的技能 + 工作流和多代理分流/深度阅读流水线——我将程序编码一次，而不是反复解释它，并将实现视为廉价且可逆的。

Now imagine a funded company, draining the money from an unfortunate VC, starting today, paying multiple feature teams A$1M a year each to have the capacity build a system that’s stable and predictable. A year of burn before they know if people like it or not.现在想象一下一家有资金的公司，从不幸的风投那里榨取资金，从今天开始，支付多个功能团队每年 100 万澳元来获得构建稳定且可预测系统的能力。在他们知道人们是否喜欢它之前，就已经烧掉了一年的资金。

I shipped it in 7 months. Alone. For less than A$5k.我在 7 个月内发布了它。独自一人。花费不到 5000 澳元。

Seems like years of progress, but I'm counting the clock in months… and this is certainly just the beginning 🤭看起来像是几年的进步，但我以月为单位计算时间……而这肯定仅仅是个开始 🤭

If you liked this, you might like Readplace, built for exactly this kind of reading.如果你喜欢这篇文章，你可能会喜欢 Readplace，它是专为这种阅读方式而构建的。

Thanks for reading. If you have some feedback, reach out to me on LinkedIn, Reddit or by replying to this post.感谢阅读。如果你有任何反馈，请通过 LinkedIn、Reddit 或回复此帖与我联系。