<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>一人公司 on Kuhung | 谷粒</title>
    <link>https://kuhung.me/tags/%E4%B8%80%E4%BA%BA%E5%85%AC%E5%8F%B8/</link>
    <description>Recent content in 一人公司 on Kuhung | 谷粒</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>zh-CN</language>
    <lastBuildDate>Wed, 29 Apr 2026 11:49:00 +0800</lastBuildDate><atom:link href="https://kuhung.me/tags/%E4%B8%80%E4%BA%BA%E5%85%AC%E5%8F%B8/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>AI时代，OPC（一人公司）的自动化与半自动化</title>
      <link>https://kuhung.me/posts/automation-and-human-in-the-loop-in-the-age-of-ai/</link>
      <pubDate>Wed, 29 Apr 2026 11:49:00 +0800</pubDate>
      
      <guid>https://kuhung.me/posts/automation-and-human-in-the-loop-in-the-age-of-ai/</guid>
      <description>如果你感觉自己三分钟热度，并为此而焦虑，这里告诉你，大部分人都这样，包括笔者：人的注意力很难长期保持，且是类似MP的消耗品，需要刻意训练+扬长避短。
成事，不仅需要财力、物力，更需要心力。为了控制心力消耗，除了常见的SMART法则拆解目标、番茄工作法保持专注外，笔者总结了一份指南：AI时代，OPC（一人公司）的自动化与半自动化。
通过下述方法，让笔者把精力放在高价值活动上。
自动化 这里的自动化，指的是自动实现某个效果，替代繁杂的人力。这个自动化本身，也是更大系统中的一部分。这里把它拆出来，是因为这些自动化环节，关乎效果和体验。
构建自动化。笔者通过GitHub和Vercel，实现自动化构建与发布。构建自动化这个事，在敏捷开发中多有提及。目前，几乎所有大厂的产品发布，都已经实现自动化。构建、打包，这个过去很耗时间的事，现在也越来越短。只有当你能够快速构建，你才能够快速迭代。无论是增加新特性，还是修复旧 Bug，构建自动化，都是提效工具。
笔者的这部分自动化，逻辑上是通过GitHub提交代码，触发Vercel的工作流，实现测试、预发和生产部署。也可以利用 GitHub Actions 的功能，做日常的调度任务，例如：数据拉取、模型计算。GitHub的Action每月提供2000min的运行时长。除开Vercel，也可以选择Cloudflare进行任务的部署，技术栈和原理类似。
指标自动化。通过 Google Analytics（GA）和 Bark，每日同步数据情况。指标，是每个项目都需要关注的内容。现代企业管理和生产，没有指标就没法优化。一般而言，产品应当关注活跃和时长指标。客户满意度无法精准测量的情况下，活跃和时长是一个基础性指标：数据量够大、又和产品的核心体验强相关。
这里的自动化，也利用了上文提到的 GitHub Actions 定时任务。通过例行任务，拉取GA的数据，再通过Bark这款手机应用，推送到手机上。这里不用Bark用邮箱也是可行的。主要目的就是每天同步线上数据情况，方便第一时间发现问题/增长点。
交付自动化，通过Stripe直接发货。这部分内容，是笔者过去小半年跑通的一个示范。先说说我们想要的效果：用户付款或者订阅，我们的软件或者文档自动开放给用户下载使用，而不是后台手工发货。很多朋友在提供服务时，往往找不到好的收款方式。也有朋友在留言，好奇是如何实现的。
当然我不建议一开始，0基础搭建这套流程，因为你的需求可能是伪需求。笔者首先在小红书和B站开店，卖出了上百份，才开始做这部分改造。目前，笔者的应用，用户可以直接实现购买、下单和资产获取，而不用笔者手工干预。这省下大量发货时间，用户的即时满足感也得到增强。
半自动化 半自动化一般借助中间工具实现，用于信息收集和内容产出工作。这部分很多时候，是为了满足信息收集和内容产出的癖好，不一定能带来真实的生产力提升。包含如下内容：
GitHub 上的 Star 同步到 Notion。笔者有大量的代码任务和感兴趣的仓库，通过 GitHub 点赞实现，但是这部分代码，有些并未转化为实际的下一步行动。究其原因，还是GitHub的点赞太方便，回顾稍微有些麻烦。笔者参考开源项目，进行了自己的改造，实现GitHub的关注自动同步到Notion，通过Notion看板，来进行任务的管理。
NotebookLM Podcast自动化，用于消化信息并产出新的信息。同样类似的，笔者也有大量的新闻资讯需要消化，进行思考并做出输出。这里笔者借助NotebookLM进行内容处理，并加工评论以防止自己成为信息转发机。在去年的基础上，迭代更新了内容资讯的生产方式，产出播客内容。
Gemini 深度研究，用来做特定研究命题的深入研究。目前谷歌整合进入Chrome侧边栏，问问Gemini。当然这个功能有时候不好使，完全看梯子的状态。为此笔者开发了平替产品，Chrome插件PageGrok。能够在任意地区，自定义模型，实现页面的解读任务。目前应用商店搜索PageGrok即可免费使用。
Cursor 写代码。有人说为啥不用 Claude Code（CC），笔者有两方面原因：一个是现在笔者是20刀500次请求的模式，算是究极性价比了；二是CC的登录验证太麻烦了，其他地方又没有稳定的高质量CC模型提供。这部分不放在完全自动化里面，是因为笔者还是不太习惯完全让AI自动运行。
AI就如同指导新同事一般，你知道它有这个能力，但是若不施加约束、进行阶段监控，只会带来返工擦屁股。直到它完全契合你的工作方式，这个时候才是放权的好时机。不过可惜，AI没法根据本地内容进行迭代。而且目前，Tier 1的模型，总是会出现过度设计和代码膨胀。放弃审查就是放弃自己。
Remotion 制作视频。通过 Remotion Skill，能够制作视频。质量在及格线附近，但聊胜于无。也算是半个自动化过程。
SEO优化。通过三方网站来实现，做到基准线水平，排除掉大的漏洞。SEO 本质上就是产出清晰、可读结构化的高质量内容。这点和内容创作无异，和编码也无异。
使用PageSpeed Insights进行网页加载优化。利用好公开的诊断工具，也不用啥都AI。
手工活 这部分，是笔者发现目前仍然难以自动化的环节。或者说，不需要自动化。
财务总结。笔者每月进行一次。盘点开支和收入情况，划分不同资产类型，进行横向比对和下月资金分配。
新知学习，需要实践，不能交给AI来做，不然学到知识的就只是AI而不是个体。
写文章，AI虽好，但是会剥夺人味，只有真情实感写出来的东西，才值得读者花时间。这部分写的过程，不可被AI替代。当然资料收集和论证环节，可以借助AI。最后发布前的语法、错别字和常识校验，笔者还是在用AI进行辅助。
项目管理。每天做了什么、下周和下个月计划做什么；之前一周和几个月，分别做了什么，有什么阶段性成果；哪部分和预期的效果不一致，需要做哪些调整，这些目前来看，是手工完成。但是目前也在做自动化改造。
因为笔者目前的项目进度，几乎都是由Notion进行管理，而Notion又是很方便同步到GitHub（利用前文逻辑），所以基本上可以通过GitHub 的Action，定时每周和每月起一个任务，来总结甘特图中的项目进展。
平台发文，纯手工但是不得不做。用自动化发文容易被封。
说到底，手工活的核心是判断力和切身感。什么该自动化、什么该亲手做，这个判断本身没法外包给AI。
总结 不要一上来就想着自动化。先做内容，而不是做工具。重复的工作要自动化，重要的指标要自动化，比如交付数量、线上数据，值得每天盯着。但判断力、审美、对受众的理解，这些没法自动化。
之前我总喜欢读书，总觉得办法在书里，先看看别人怎么做的。这个思路是对的，很多问题和解决方案，早在别人那里有过。现在，书也要看，人也要谈，更多的是从实践和面对面输出中，获取连结感和下一步行动力。
虽然现在AI自动研究的话题很火，但我认为它更像是一个范围命题。这场AI show，什么时候落幕不知道，但需要更多的关于边界的自我认知。追逐热点，奉为圭臬的人往往更FOMO，更容易被营销带偏。偶尔跟不上热点，并非坏事。AI这个行当，曾经的热点，过几个月，就不再是了。
最好的方式，就是控制流入，高价值利用自己的核心工作时间。笔者这套体系一直在迭代，随着工具和需求变化，持续调整。
保持敏锐，但拒绝焦虑。持续输出。
关于作者</description>
    </item>
    
  </channel>
</rss>
