跳到正文
DEV Community· Sungsoo Youn·· 3 小時前AI 評分42

我的儀錶板叫我申請書店發售,兩家其實已在賣我的書

My Dashboard Told Me to Apply to the Bookstores. Two of Them Were Already Selling My Book.

AI 導讀

Claude Code 智能體在 10 月 12 日查看銷售管理頁面時,發現 8 間書店中已有 2 間在售,另有 5 間仍待處理;申請早於 8 月 31 日提交,提醒卻因帳簿欄位一直空白而誤報。修正後,智能體每日讀取各書店狀態及賣家後台的月度銷售表,並在無法讀取數據時不記錄銷售額。

正文

A field note from the autonomous Claude Code agent I run every day on one Windows PC. The numbers come from its own ledgers, not from memory.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

In an earlier note I wrote about a waiting clock for my book's ISBN. The Korean edition sells on a Korean e-book platform, and that platform passes books on to bookstores once they have an ISBN. At the end of that fix I added one more line to my agent's evening summary: when an ISBN number appears, ring a bell that says it is time to request bookstore distribution, and keep it until the request is recorded.

The ISBN was approved on October 6. From October 7 to October 11, five evening summaries carried the bell. The bell even carried its own warning: requesting sale again may send the book back to waiting for approval.

Reading before pressing

On October 12 my agent went to make the request. It opened the screens and read them first, without pressing any button that changes state.

The sales management screen listed eight bookstores, all requested on August 31, the day the book was first submitted for sale. Two showed on sale. One showed sent. Five showed request pending.

The platform's seller help says that a book without an ISBN cannot be sent to partner bookstores, so its requests are held. Nobody had asked again after the ISBN arrived, yet three of the eight had gone out. Five were still pending.

So the request had been made 42 days earlier. The bell asked for something already done. Following it could have cost something. When my agent resubmitted the book on October 1 to replace its file, the status went back to waiting for approval, and the agent read it as on sale again on October 2.

October 12 is only the day I first saw the two bookstores selling it. When they started, I do not know.

Why the bell was wrong

The bell did check for a record of the request. It looked for one field in my agent's ledger. But no code ever filled that field, so it stayed empty. Meanwhile the same ledger already held the August 31 sale request and the list of eight bookstores, and the bell did not look at those. The status of each bookstore was on a screen my agent did not read.

The evening run now reads the sales management screen every day and stores each bookstore's status and the first day it was seen on sale. The summary shows the real status. It rings only when a bookstore rejects or stops the book. If the status cannot be read, it says the status is unknown and that the request should not be repeated.

This fix came with 10 tests, and 8 of the first 9 failed against the old code. My auditor rejected the first pass: the evening run now read one more screen, but two descriptions still said three. It also pointed out that the new screen's address belonged to one book, so it now reads that screen only for that book.

The second gap

The next question was whether my revenue goal would see a bookstore sale. My revenue meter read the sales count on the platform's own public page. Bookstore sales show up in a monthly sales table in the seller dashboard, and they are added once a month, on the 10th.

The evening run now reads that table every day. Two details mattered.

  • The table also has a column for the platform's own sales. Those are already counted from the public page, so the meter leaves that column out. Otherwise one sale would count twice.
  • December sales arrive on January 10, in the previous year's table. So the meter reads every year's table from 2026 to the current year. If any one year cannot be read, it records nothing that day.

This came with 13 tests, and all 13 failed against the old code. The baseline on October 12 was 0.

Two things I do not know yet. Whether the numbers in that table are sale prices or the amount paid out to me. And whether the public page's sales count already includes bookstore sales; if it does, the new meter counts them twice. The first bookstore figures are due on November 10, and that is the day to check both.

The rules

  • A reminder that waits for a record needs code that writes the record. An empty field that nothing fills makes the reminder ring forever.
  • Read the screen before pressing the button a reminder asks for. This bell came with its own warning about that button.
  • For every new place that sells, find the screen where its money shows up. The public page my meter read and the dashboard table where bookstore sales appear were different screens.

Where this comes from. Every post here comes from one setup I run daily: a CLAUDE.md, memory files the agent reads before it touches anything, and a separate auditor agent that returns PASS or FAIL. The first 3 chapters of the book that walks through it are free as a PDF: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

The full edition is 11 chapters plus 4 ready-to-use templates (CLAUDE.md starter, memory files, auditor checklist, measurement guide) and a hands-on section for every chapter, $19 as a PDF: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.

來源:DEV Community · dev.to