你有没有遇到过这种情况？

老板发来一张发票照片让你录入报销系统，你只能对着屏幕一个字一个字地敲；收到一份扫描版的合同PDF，想复制里面的文字却发现根本选不中。

这些看似琐碎的小事，其实都指向同一个问题：如何把图片里的文字变成可以编辑的电子文档？

PaddleOCR就是专门解决这个问题的。

你给它任何包含文字的图片、PDF、甚至手写笔记的照片，它都能在几秒钟内把所有文字提取出来，变成你可以直接复制粘贴的文本。

GitHub🔗：https://github.com/PaddlePaddle/PaddleOCR

它认识80多种语言的文字。
不管是中文、英文、日文，还是繁体字、手写体，甚至是那种歪歪扭扭的医生处方，它都能认出来。

准确率也非常高，基本上人眼能看清的文字，它都不会认错。

而且，它不只是把文字提取出来这么简单。

比如你给它一份包含表格的文档，它会保留表格的结构；给它一份带标题、段落的报告，它会维持原有的排版格式。

这意味着你拿到的不是一堆乱七八糟的文字，而是可以直接使用的规范文档。

即使你不是程序员，PaddleOCR也能帮到你。

市面上很多OCR软件都是基于它开发的，比如Umi-OCR这样的桌面工具。你可以用它来：
● 把纸质书籍转成电子书
● 整理家庭档案和老照片上的文字
● 快速提取网页截图里的内容
● 把手写笔记转成Word文档

最重要的是，它完全免费开源！
这意味着你不用花几百块买OCR软件，也不用担心隐私泄露（因为可以完全在自己电脑上运行）。

如果你经常需要处理文档，或者想让工作更高效，PaddleOCR绝对值得了解。

它把"从图片提取文字"这件事，从一个技术难题变成了一个简单操作，这就是技术改变生活的最好例子。

以前团队人少，协作起来也没啥太多规矩，但基本上也都在我掌控之中，大家都舒服，也不耽误事。

现在事多、人多了，协作的线也多了，我居然开始焦虑了。

做过就会知道，在小团队里，不可能有那种清晰的分工和协作，也不会有一个人可以完整的负责某个模块，这不现实。

真实情况是，每个人都是负责几个点，这几个点之间没有啥联系，甚至也没什么逻辑。清晰的分工和目标，并不是最重要的，能快速落地才是第一。

可能每个人都不喜欢混乱，包括我，但对于一个灵活的组织来说，保持一定的混乱状态，才能保持活力。

我可以持续的、试图让目标、路径、协作变得清晰一些，但这就像给一个8岁孩子收拾房间，每天收拾每天乱，一定要做但肯定无法持续。

这个反向的推广帖子也挺有意思的
平时大家都说我赚了10k 20k 50k
这哥们是干了俩月0收入
评论区可就更扎心了 说期望你达到3个月0收入
建议你那时候邀请家人去遛弯庆祝 笑死

看大家在聊CC和Codex
我觉得如果条件允许，就都买吧

CC处理前端比较好，然后处理一些流程性作业也不错，比如做SEO之类的
Codex修bug比较强一些，但前端设计上明显不如CC

都买是取长补短了

最近很多小红书商家都收到了当你年GMV超过10w，让升级自己店铺的事
这是大势所趋，小红书的自然流越来越难有红利了，但是付费投流依旧有很大的想象空间
但是最最最核心，拼的还是内容素材
做好内容，做好种草，做好场景塑品，是核心课题。

NotebookLM 的月活高达 4000 万了。

新的 「生成视频」的功能水准十分在线。

开源一个简单的 CMS， 95% 代码由 Claude Code 完成，代码质量可靠，附开发记录。

一个简单的内容管理系统，可以将多个网站的博客内容集中管理，支持 API 接口读取，支持部署在 Cloudflare 。

为什么要做这个？我之前打算用 React Router 做一个 SSR 的网站，想部署在 Cloudflare Worker 上，但是因为 Edge 环境的诸多限制，导致开发一个支持 markdown 写作的博客功能很困难，比如因为 Edge 环境不支持 fs 等库，导致无法动态读取博客列表。一个替代的方案是部署一个开源的 CMS 系统来管理内容，通过 API 读取，但是开源 CMS 系统都太重了，学习成本很高，维护成本也高。所以就想自己做一个简单的 CMS 系统，仅支持有限的功能。

该 CMS 有两个模块：CLI 前端和后端服务，支持以下功能：

- 支持用 mdx 在本地写作，支持元数据及内容格式校验，支持通过 CLI 上传
- 支持通过 CLI 上传本地图片到 Cloudflare R2
- 支持博客文章创建、列表查询、详情查询接口
- 支持博客多语言
- 支持多个网站及每个网站单独鉴权
- 支持博客列表分页

经过测试，项目部署成功后可正常使用。

开发过程全记录

使用 Claude Code 做个 CMS（一）https://mp.weixin.qq.com/s/PZwiYSFl7tPMcQCcdddsSA

使用 Claude Code 做个 CMS（二）https://mp.weixin.qq.com/s/vfAonJi1d7r3e-YXW6Imsw

使用 Claude Code 做个 CMS（三）https://mp.weixin.qq.com/s/VnN5iH10X3ji7LF1FY0HUg

使用 Claude Code 做个 CMS（四）https://mp.weixin.qq.com/s/Fg62V1mqAYrKp6mRnDyLrg

使用 Claude Code 做个 CMS（五）https://mp.weixin.qq.com/s/I2YwHbs6GvEFNL6mvPIUoA

使用 Claude Code 做个 CMS（六）https://mp.weixin.qq.com/s/Ccy2u1pUNUKDp4TEtDbQmg

这不就小灵通？

最近我一直在探索做什么副业有机会，但是研究一圈下来，要不就是没需求，要不就是市场太卷，要不就是自己没能力做，很绝望。

靠产品取胜太难了，单枪匹马很难做出市场有竞争力的产品。

所以仔细琢磨下来，对我来说，未来应该是个人 ip 驱动，而不是产品驱动，不是靠产品本身足够优秀赚到钱，而是靠大家认可你这个人，相信你推荐的产品，推啥买啥，

就像小米一样，品牌打出来了，给我的感觉就是体验好，价格便宜，细节设计周到，所以只要我想买个什么东西，小米有，我一定是无脑买。

特别是 AI 时代，机器太强大了，可以帮人类解决太多的东西，功能性的更加不缺，反而会突出有人性有温度的个人ip内容，

所以，未来在产品层面，除非是尖端领域，否则一定是血海一片，杀个头破血流，想要做出点成绩难上加难，

靠产品来驱动是不行的，而是要靠人来驱动，不断地创作内容，分享自己的工作，生活，思考等等，真诚地表达自己的一切，最终靠信任转化为产品的销售，这应该是一条更加适合我这种普通人走的路。

另外，对于个人ip来说，能量比干货重要，干货是功能性的，AI未来几乎都能解决，只有个体表达散发的态度，精神面貌，情绪等等才是个人 ip 应该走的路，是AI没法替代的，就像我们交朋友一样，吸引我们的是身上散发出的能量感，而不是干货。

所以，我创作的都是这种随性的短文，不能让人学到什么知识或深度分析，也不打算这么做，我只想表达当下的情绪，态度，观点，这也是我实实在在的状态，真想学知识，找AI去哈哈哈。

总结一句，未来靠个人ip 驱动而非产品驱动，做个人ip内容，靠能量不靠干货!

希望我睡醒的时候，CLI已完整地实现了我的程序目标 ：）

你知道吗？Claude Code这个产品的诞生纯属意外。

2024年初，Anthropic的工程师Boris只是想更好地理解自家的API，于是顺手写了个小工具。
这个在终端里运行的简陋程序，看起来就像是上世纪的DOS界面，黑底白字，连个按钮都没有。

但奇怪的事情发生了，Boris团队里的其他工程师开始偷偷使用这个工具。
然后是整个技术部门。
再然后，连研究员、数据科学家，甚至产品经理和设计师都开始用了。

在正式对外发布前，这个连名字都还没定的工具，已经在Anthropic内部拥有了近千名用户。

"我当时在做强化学习环境的搭建，发现这个工具能让我的效率提升好几倍，"产品负责人Cat Wu回忆道。
她原本只是兼职帮Boris提产品建议，结果反馈越提越多，最后干脆全职加入了团队。

这种自下而上的产品诞生路径，在硅谷并不罕见。
Gmail是谷歌工程师的20%时间项目，Facebook的News Feed最初也只是个内部实验。

但Claude Code的特别之处在于，它几乎完全依靠口碑传播，没有任何推广，病毒系数却高得惊人。

打开Claude Code，你会觉得自己穿越回了1980年代。
没有花哨的界面，没有炫酷的动画，甚至连个图标都没有。
就是一个光标在那里闪烁，等待你的输入。

这种设计不是因为懒，而是一种刻意的选择。

"终端界面的美妙之处在于，它能访问开发者能访问的几乎所有东西，"Cat解释道。
通过命令行，Claude Code可以调用GitHub CLI、Datadog CLI，或者任何其他命令行工具。

对熟悉终端的开发者来说，上手几乎是零成本的。

但极简不代表简陋。团队在功能设计上遵循一个原则：新功能不需要任何使用说明。
用户看到功能名称和一行描述，就应该立刻明白它是干什么的。

这种"零文档"的设计理念，逼迫团队在每个细节上都要深思熟虑。

比如那个看似简单的待办事项功能。
最初，工程师Sid发现Claude Code在处理大型重构任务时，经常做了前5个步骤就忘记后面的25个。

解决方案出人意料的简单：强制模型写下所有要做的事，就像人类一样列个清单。
结果效果立竿见影，模型的任务完成率大幅提升。

但找到合适的展示形式却花了几个月。
最开始，待办事项只是在终端里一闪而过。后来发现用户需要随时查看进度，于是改成了持久显示。
团队还尝试过把它放在"思考气泡"里，但用户反馈说太碍眼。

最终，他们选择了一个独立的命令，用户可以随时调用查看。

在Anthropic内部，有一个专门的Slack频道，里面聚集了上千名Claude Code的内部用户。
这个频道的消息更新频率惊人：平均每10分钟就有一条新反馈。

"我们特别喜欢负面反馈，"Cat说得很直接，"不要客套话，就告诉我们哪里不好用。"
这种"狗粮测试"（dogfooding）的文化，让Claude Code的迭代速度快得惊人。

一个功能从想法到内部测试，可能只需要几天。如果反响好，一两周后就能推送给外部用户。
如果反响差，直接砍掉，连文档都不用写。

在传统软件公司，产品经理写PRD，工程师写代码，设计师画界面，分工明确，井水不犯河水。
但在Claude Code团队，这些界限几乎不存在。

设计师Megan以前从来不碰代码，用了Claude Code后，她开始向代码库提交PR（Pull Request）。
不是简单的文案修改，而是真正的功能代码。

产品经理Cat自己也经常改bug，甚至独立开发小功能。

这种工作方式的转变，不仅仅是效率的提升，更重要的是，它打破了传统软件开发中的信息传递损耗。
产品经理不用费尽口舌解释需求，设计师不用画详细的标注图，每个人都可以直接把想法变成代码。

AI产品最大的挑战之一，是如何评估产品质量。
传统软件可以用崩溃率、响应时间这些指标，但AI产品的好坏往往很主观。

Claude Code团队采用了两种评估方法。
第一种是端到端评估，类似于跑基准测试，看模型能否完成特定的编程任务。
但这种方法很粗糙，"如果分数变化了，你得读一堆复杂的日志才能搞清楚原因，"Cat坦言。

第二种是触发评估。比如网页搜索功能，什么时候该触发，什么时候不该触发？
团队会设置明确的场景：问"最新的React版本"时应该搜索，问"Python的for循环怎么写"时不应该搜索。
这种评估相对精确，但只能覆盖部分功能。

说到底，最可靠的评估还是用户反馈。团队与10家早期企业用户保持密切联系，要求他们"尽可能挑刺"。
有问题一周内修复，这是团队给自己定的死线。

哲学家卡尔·波普尔说过："我们的知识只能是有限的，而我们的无知必然是无限的。"
在AI产品开发这个充满未知的领域，Claude Code团队选择拥抱这种不确定性。他们不写冗长的规划文档，不开马拉松式的评审会议，只是不断地构建、测试、迭代。

或许，这才是AI时代产品开发的正确姿势：保持简单，快速行动，让产品自己找到方向。

正如团队内部流传的一句话：代码库就是最好的文档，用户反馈就是最好的指南针。

nanobanana真的比字节的模型强好多啊。。。。