文章庫

小夥伴們大家好，我是小溪，見字如面。OpenSpec升級到了1.x版本，玩了2天發現相對於老版本來說還是有不小變動的，不僅提供了更靈活的協同工作流程，還支持了自定義工作流模式。習慣使用老版本和對老版本OpenSpec還不瞭解的小夥伴也可以往期內容：初識OpenSpec當前使用版本openspec 1.2.0優勢輕量化、靈活性和可擴展性進一步提高向下兼容，舊版變更可以使用 OPSX 命令繼續，製品結構是兼容的新增Skills技能調用方式更節省tokens提供更細粒度的擴展命令協同工作流程OpenSepc新版本協同工作流程如下：如何使用？需要 Node.js 20.19.0 或更高版本首先更新OpenSpec至最新版本，在命令行終端輸入如下命令：$ npm install -g @fission-ai/openspec@latest更新完成後，新項目直接進入項目根目錄進行初始化$ cd your-project$ openspec init舊項目也是可以用的，作者建議使用新版本命令，可以直接進入項目根目錄進行更新$ cd your-project$ openspec update想了解更多OpenSpec內容，但又看不太習慣英文的小夥伴，可以看OpenSpec社區中文版本，Github倉庫地址：https://github.com/studyzy/OpenSpec-cn，這裏給好心人點個贊基本使用命令行指令OpenSpec擴展了新的命令行指令，在命令行終端輸入 openspec -h 可以查看完整的命令行幫助文檔，這裏只列舉新增的功能，對已存在的指令還不瞭解的小夥伴可以看往期內容：初識OpenSpecconfig：查看並修改全局OpenSpec配置schema：管理工作流程模式feedback：提交OpenSpec反饋completion：管理OpenSpec CLI的Shell補全generate：生成Shell補全腳本install：安裝Shell補全腳本uninstall：卸載Shell補全腳本status：顯示變更的製品完成狀態instructions：輸出用於創建制品或執行任務的增強指引templates：顯示 Schema 中所有制品的解析後模板路徑schemas：列出可用的工作流 Schema 及其描述new：創建一個新的變更OpenSpec新增了CLI Shell自動補管理，我們只需要在命令行終端執行下面命令就會自動安裝$ openspec completion install安裝完成後重啓命令行終端，輸入 openspec comp 按下【Tab】快捷鍵就可以看到命令的自動補全效果了自定義命令和SkillsOpenSpec新版本提供了一套以 /opsx: 前綴的自定義命令和以 openspec- 為前綴的SkillsOpenSpec默認提供了4個自定義命令：/opsx:explore：深入思考想法、調查問題、明確需求，用於需求前的頭腦風暴/opsx:propose：開始一個新變更，會一次性生成所有規劃階段的製品如 proposal、specs、design、tasks/opsx:apply：實施變更中的任務，AI 會根據 tasks.md 中的任務清單逐一實現功能/opsx:archive：歸檔已完成的變更，會把整個變更文件夾移入存檔並將增量規範合併到主規範庫除了這套核心命令，OpenSpec還提供了一套更細粒度的擴展命令，需要通過 openspec config命令配置進行開啓。開啓需要在命令行終端輸入以下命令：$ openspec config profileDelivery：在哪裏安裝工作流，比如在 Skills、CommandsWorkflows：工作流中哪些設計指令是可用的，比如 /opsx:explore、/opsx:new可以靈活選擇配置方式，這裏我選擇【Delivery and workflows】兩者都配置，接下來會先配置Delivery，選擇Both同時生成Skills和Commands然後配置Workflows使用【Space】快捷鍵選中需要的命令最後輸入【Y】確認更新完成後就可以看到更新後的全部配置了OpenSpec其他自定義命令：/opsx:new：開始一個新變更，只創建一個空的變更目錄/opsx:continue：基於依賴關係創建下一個製品，就是一步步創建 proposal、specs、design、tasks/opsx:ff：Fast-Forward 快速一次性創建所有規劃製品 proposal、specs、design、tasks/opsx:verify：校驗實現是否與製品匹配/opsx:sync：將增量規範合併到主規範中，通常不需要手動執行/opsx:bulk-archive：批量歸檔多個變更/opsx:onboard：完整的 OpenSpec 工作流引導教程OpenSpec目錄結構OpenSpec新版本目錄結構也發生了變化，移除了 project.md 和 AGENTS.mdopenspec/├── config.yaml # 新增，項目上下文和規則配置├── project.md # 已移除，項目規範約定├── AGENTS.md # 已移除，為Agent提供的OpenSpec使用說明，├── specs/ # 源規範目錄，每次變更歸檔後會合併到這裏│ ├── spec.md # 源需求和場景規範│ └── design.md # 源技術模式├── changes/ # 提案變更目錄│ ├── [change-name]/ # 單個提案變更│ │ ├── proposal.md # 為什麼，什麼，影響│ │ ├── tasks.md # 實施檢查清單│ │ ├── design.md # 技術決策（可選；見標準）│ │ └── specs/ # 增量變更規範│ │ └── [capability]/│ │ └── spec.md # ADDED/MODIFIED/REMOVED│ └── archive/ # 已完成的提案變更項目初始化使用OpenSpec新版本初始化項目，首先在命令行終端進入到項目根目錄，執行 openspec init，使用【space】快捷鍵選擇自己使用的AI工具確認配置後回車使用IDE打開可以看到如下目錄結構，在 commands/ 目錄下創建了 opsx/ 命令集，在 skills/ 目錄下創建了對應的技能，同時創建了openspec 配置目錄創建變更提案OpenSpec新版本創建變更提案的命令和老版本沒有太大差異，只是做了命令的變更，新版本可以使用 /opsx:propose 需求描述創建創建變更，也可以使用 /opsx:new 需求描述創建創建變更，甚至可以通過自然語言使用Skills能力創建變更提案創建一個登錄授權功能提案這裏以新版本提供的 /opsx:new 命令為例，記錄一下創建變更提案的流程。首先使用下面命令創建一個變更提案：/opsx:new 創建一個登錄授權功能可以OpenSpec只創建了變更目錄 add-login-auth 和 .openspec.yaml文件並沒有創建我們之前所熟悉的 proposal.md、specs/[capability]/spec.md、design.md 和 tasks.md要創建上面所需的配置文件，我們需要再次執行 /opsx:continue 命令，到這一步OpenSpec才真正開始創建變更提案內容，與AI確定好問題邊界後提交執行完成後，可以看到此時才創建了 add-login-auth/proposal.md相當於單步執行檢查提案沒有問題後再次執行 /opsx:continue 會繼續生成 add-login-auth/design.md待 proposal.md、design.md、tasks.md 都生成後，再次 /opsx:continue OpenSpec會檢查artifacts狀態，告訴我們下一步該執行的操作當然也可以創建提案後直接執行 /opsx:ff，一步完成所有artifacts工作，到這裏變更提案階段就算完成了，下一步就可以實施任務了。實施任務與歸檔實施任務、歸檔操作和舊版本也沒有太大變化，只是將命令調整為了 /opsx:apply 和 /opsx:archive，歸檔後的文件目錄和舊版本也基本是保持一致的自定義項目配置OpenSpec提供了項目配置、自定義模式、全局覆蓋 3個級別的自定義：項目配置：針對項目生效，位於 openspec/schemas/，支持設置默認值，注入上下文/規則，適合大多數團隊自定義模式：定義自己的工作流製品，適合有獨特流程的團隊全局模式：針對所有項目生效，位於 ~/.local/share/openspec/schemas/，在所有項目間共享模式，適用於高級用戶項目配置在移除 project.md 和 agent.md 後，OpenSpec新版本中新增了 openspec/config.yaml 文件承擔了部分原本由這些文件負責的“項目常識”管理功能。openspec/config.yaml 文件是為團隊自定義OpenSpec的最簡單方法，它允許我們：設置默認模式：在每個命令上跳過 --schema注入項目上下文：AI 看到你的技術棧、約定等添加每個製品的規則：特定製品的自定義規則默認工作模式的配置方式大致如下：# openspec/config.yamlschema: spec-drivencontext: | 技術棧：TypeScript、React、Node.js API 約定：RESTful、JSON 響應測試：Vitest 用於單元測試、Playwright 用於端到端測試代碼風格：ESLint 搭配 Prettier、嚴格 TypeScriptrules: proposal: - 包含回滾計劃 - 識別受影響的團隊 specs: - 使用 Given/When/Then 格式描述場景 design: - 為複雜流程包含序列圖自定義模式當項目配置不夠時，創建具有完全自定義工作流的模式。自定義模式位於項目的 openspec/schemas/ 目錄中，並與代碼一起進行版本控制。your-project/├── openspec/│ ├── config.yaml # 項目配置│ ├── schemas/ # 自定義模式在此│ │ └── my-workflow/│ │ ├── schema.yaml│ │ └── templates/│ └── changes/ # 你的變更└── src/創建自定義模式最快的方法是派生內置模式，即通過克隆複製一份默認的內置模式$ openspec schema fork spec-driven my-workflow這個命令會將整個 spec-driven 模式複製到 openspec/schemas/my-workflow/ 目錄下文件大致描述如下：openspec/schemas/my-workflow/├── schema.yaml # 工作流定義└── templates/ ├── proposal.md # 提案製品的模板 ├── spec.md # 規範的模板 ├── design.md # 設計的模板 └── tasks.md # 任務的模板系統內置的提示詞模版如下：# schema.yamlname: my-workflowversion: 1description: Default OpenSpec workflow - proposal → specs → design → tasksartifacts:- id: proposal generates: proposal.md description: Initial proposal document outlining the change template: proposal.md instruction: > Create the proposal document that establishes WHY this change is needed. Sections: - **Why**: 1-2 sentences on the problem or opportunity. What problem does this solve? Why now? - **What Changes**: Bullet list of changes. Be specific about new capabilities, modifications, or removals. Mark breaking changes with **BREAKING**. - **Capabilities**: Identify which specs will be created or modified: - **New Capabilities**: List capabilities being introduced. Each becomes a new `specs/<name>/spec.md`. Use kebab-case names (e.g., `user-auth`, `data-export`). - **Modified Capabilities**: List existing capabilities whose REQUIREMENTS are changing. Only include if spec-level behavior changes (not just implementation details). Each needs a delta spec file. Check `openspec/specs/` for existing spec names. Leave empty if no requirement changes. - **Impact**: Affected code, APIs, dependencies, or systems. IMPORTANT: The Capabilities section is critical. It creates the contract between proposal and specs phases. Research existing specs before filling this in. Each capability listed here will need a corresponding spec file. Keep it concise (1-2 pages). Focus on the "why" not the "how" - implementation details belong in design.md. This is the foundation - specs, design, and tasks all build on this. requires: []- id: specs generates: specs/**/*.md description: Detailed specifications for the change template: spec.md instruction: > Create specification files that define WHAT the system should do. Create one spec file per capability listed in the proposal's Capabilities section. - New capabilities: use the exact kebab-case name from the proposal (specs/<capability>/spec.md). - Modified capabilities: use the existing spec folder name from openspec/specs/<capability>/ when creating the delta spec at specs/<capability>/spec.md. Delta operations (use ## headers): - **ADDED Requirements**: New capabilities - **MODIFIED Requirements**: Changed behavior - MUST include full updated content - **REMOVED Requirements**: Deprecated features - MUST include **Reason** and **Migration** - **RENAMED Requirements**: Name changes only - use FROM:/TO: format Format requirements: - Each requirement: `### Requirement: <name>` followed by description - Use SHALL/MUST for normative requirements (avoid should/may) - Each scenario: `#### Scenario: <name>` with WHEN/THEN format - **CRITICAL**: Scenarios MUST use exactly 4 hashtags (`####`). Using 3 hashtags or bullets will fail silently. - Every requirement MUST have at least one scenario. MODIFIED requirements workflow: 1. Locate the existing requirement in openspec/specs/<capability>/spec.md 2. Copy the ENTIRE requirement block (from `### Requirement:` through all scenarios) 3. Paste under `## MODIFIED Requirements` and edit to reflect new behavior 4. Ensure header text matches exactly (whitespace-insensitive) Common pitfall: Using MODIFIED with partial content loses detail at archive time. If adding new concerns without changing existing behavior, use ADDED instead. Example: ``` ## ADDED Requirements ### Requirement: User can export data The system SHALL allow users to export their data in CSV format. #### Scenario: Successful export - **WHEN** user clicks "Export" button - **THEN** system downloads a CSV file with all user data ## REMOVED Requirements ### Requirement: Legacy export **Reason**: Replaced by new export system **Migration**: Use new export endpoint at /api/v2/export ``` Specs should be testable - each scenario is a potential test case. requires: - proposal- id: design generates: design.md description: Technical design document with implementation details template: design.md instruction: > Create the design document that explains HOW to implement the change. When to include design.md (create only if any apply): - Cross-cutting change (multiple services/modules) or new architectural pattern - New external dependency or significant data model changes - Security, performance, or migration complexity - Ambiguity that benefits from technical decisions before coding Sections: - **Context**: Background, current state, constraints, stakeholders - **Goals / Non-Goals**: What this design achieves and explicitly excludes - **Decisions**: Key technical choices with rationale (why X over Y?). Include alternatives considered for each decision. - **Risks / Trade-offs**: Known limitations, things that could go wrong. Format: [Risk] → Mitigation - **Migration Plan**: Steps to deploy, rollback strategy (if applicable) - **Open Questions**: Outstanding decisions or unknowns to resolve Focus on architecture and approach, not line-by-line implementation. Reference the proposal for motivation and specs for requirements. Good design docs explain the "why" behind technical decisions. requires: - proposal- id: tasks generates: tasks.md description: Implementation checklist with trackable tasks template: tasks.md instruction: > Create the task list that breaks down the implementation work. **IMPORTANT: Follow the template below exactly.** The apply phase parses checkbox format to track progress. Tasks not using `- [ ]` won't be tracked. Guidelines: - Group related tasks under ## numbered headings - Each task MUST be a checkbox: `- [ ] X.Y Task description` - Tasks should be small enough to complete in one session - Order tasks by dependency (what must be done first?) Example: ``` ## 1. Setup - [ ] 1.1 Create new module structure - [ ] 1.2 Add dependencies to package.json ## 2. Core Implementation - [ ] 2.1 Implement data export function - [ ] 2.2 Add CSV formatting utilities ``` Reference specs for what needs to be built, design for how to build it. Each task should be verifiable - you know when it's done. requires: - specs - designapply: requires: - tasks tracks: tasks.md instruction: | Read context files, work through pending tasks, mark complete as you go. Pause if you hit blockers or need clarification.# proposal.md## Why## What Changes## Capabilities### New Capabilities- `<name>`: <brief description of what this capability covers>### Modified Capabilities- `<existing-name>`: <what requirement is changing>## Impact# spec.md## ADDED Requirements### Requirement: #### Scenario: - **WHEN** - **THEN**  # design.md## Context## Goals / Non-Goals**Goals:****Non-Goals:**## Decisions## Risks / Trade-offs# tasks.md## 1. - [ ] 1.1 - [ ] 1.2 ## 2. - [ ] 2.1 - [ ] 2.2 當然我們也可以從0開始創建全新的工作流，我們可以自定義一個模式，在每次提案之前需要先進行調研，提案後直接產生tasks為例，在命令行終端輸入如下指令：$ openspec schema init research-first或者$ openspec schema init research-first --description "快速迭代工作流" --artifacts "proposal,specs,tasks"輸入Schema描述，選擇artifacts製品確認配置輸入【y】回車選擇將 research-first 設置為默認Schema創建完成後，我們將得到一個Schema項目# schema.yamlname: research-firstversion: 1description: "調研驅動工作流：Research -> Proposal -> Tasks"artifacts:- id: research generates: research.md description: "初步調研與可行性分析" template: research.md instruction: | 針對用戶需求進行深度調研。 1. 分析當前代碼庫的相關實現。 2. 提出至少兩種可能的實現思路。 3. 評估各方案的優缺點及潛在風險。 requires: []- id: proposal generates: proposal.md description: "最終選定的實施提案" template: proposal.md instruction: | 基於 research.md 的調研結果，確定最終實施方案。 1. 明確變更的具體範圍。 2. 描述對現有系統架構的影響。 3. 定義成功交付的標準。 requires: [ research ]- id: tasks generates: tasks.md description: "可執行的任務清單" template: tasks.md instruction: | 根據 proposal.md 的內容，分解為可直接執行的代碼任務。 1. 任務需具備原子性（每個任務對應 1-2 個文件修改）。 2. 包含必要的測試任務。 requires: [ proposal ]apply: requires: [ tasks ] tracks: tasks.md配置項字段：id：唯一標識符，用於命令和規則generates：輸出文件名（支持通配符如 specs/**/*.md）template：templates/ 目錄中的模板文件instruction：AI 創建此製品的指令requires：依賴項 - 哪些製品必須先存在# research.md# Research: {{change_name}}## 1. 現狀分析## 2. 方案探索### 方案 A: [簡述]- **實現路徑**: - **優點**: - **風險**: ### 方案 B: [簡述]- **實現路徑**: - **優點**: - **風險**: ## 3. 調研結論# proposal.md# Proposal: {{change_name}}## 1. 變更目標## 2. 詳細變更內容- [ ] 修改點 A- [ ] 新增組件 B## 3. 技術約束- 涉及文件: - 性能/安全考慮:# tasks.md# 任務清單## 前置任務- [ ] 完成 research.md 的撰寫和審核- [ ] 完成 proposal.md 的撰寫和審核## 實施任務- [ ] [任務1描述]- [ ] [任務2描述]- [ ] [任務3描述]- [ ] ... ## 測試任務- [ ] [測試任務1描述]- [ ] [測試任務2描述]- [ ] [測試任務3描述]- [ ] ... ## 文檔任務- [ ] 更新相關技術文檔- [ ] 編寫用戶手冊或操作指南- [ ] 記錄變更日誌## 審核任務- [ ] 代碼審核- [ ] 測試報告審核- [ ] 文檔審核接下來修改 openspec/config.yaml 文件，配置 research-first 為默認schema或者使用命令行指定$ openspec new change feature --schema research-first 在使用自定義schema之前，我們需要先對它進行驗證，在命令行終端輸入命令$ openspec schema validate research-first驗證沒有問題後就可以重新創建變更提案了/opsx:propose 添加暗黑模式最終效果如下，OpenSpec按照我們提供的工作流模版輸出了對應的變更提案製品，檢查無誤後就可以實施任務了。全局模式OpenSpec也支持用戶級schema，位於 ~/.local/share/openspec/schemas/，用於跨項目共享，但是更推薦使用項目級schema，因為它們與你的代碼一起進行版本控制，使用方式和自定義一致。點擊關注，及時接收最新消息

完成

0基礎玩轉obsidian：AI時代必備本地知識庫工具

AI時代用Obsidian做本地知識庫底座，由安裝到進階完整指南

完成

什麼？AI居然要花錢用

AI 收費唔係離譜，離譜係你冇諗過佢點生存

完成

Anthropic 兄妹 Dario Amodei 和 Daniela Amodei 最新對話：Claude 為什麼一直限速？

Anthropic 因 80 倍增速被迫限速，組織級 AI 係未來六個月最令人興奮嘅能力

完成

花費260元，我給各家 Coding Plan 從夯到拉排名

K姐自費260蚊實測7款Coding Plan，火山引擎方舟性價比最高，智譜GLM-5-Turbo表現頂級但難搶

完成

這個封裝了我3年自媒體經驗的AI熱點網站，今天向所有人免費開放。

作者公開咗自己用嚟監控AI熱點嘅網站，背後係三年自媒體經驗同11版評分策略嘅迭代。

完成

豆包 Seed 2.0 Lite升級：給 Agent 裝上眼睛和耳朵

豆包 Seed 2.0 Lite 升級，用低價全模態畀 Agent 睇片聽嘢，解決字幕痛點

完成

Codex 新命令 /goal 深度解析

/goal 命令令 Codex 擁有長任務追蹤能力，背後係持久化加運行時核算嘅實踐

完成

從 Prompt 到 Harness：AI 編程真正缺的是工程紀律

AI編程真正缺嘅係工程紀律，唔係更勁嘅prompt。呢篇整理《Harness Engineering橙皮書》嘅方法論，教你建立指令、回饋、記憶同編排系統，令AI穩定產出。

完成

當我把鍵盤放下，對着AI說了一天話來解決我的日常工作

用語音同AI協作，將碎片時間嘅產出密度翻倍：TRAE SOLO + Insta360 Mic Air 實戰分享

完成

Cloudflare 聯手 Stripe：讓 Agent 自己開賬號買域名

Cloudflare 聯手 Stripe：讓 AI Agent 自己開賬號、註冊域名、畀錢

完成

把視頻變成圖文博客：Agent + 豆包 Seed2.0 lite 重做 Karpathy 兩年前的工作流

用多模態Agent工作流，將技術演講視頻自動轉成圖文並茂嘅博客，效率大幅提升

完成

只有不斷迭代，才能讓 AI 的進步指數倍反饋到自己身上

不斷迭代先係AI時代嘅真正槓桿——作者用三年實戰經驗話你知點樣駕馭模型

完成

Codex必須要安裝的1個工具包！awesome-codex-skills實戰筆記，讓Codex真正「幹活」了

Awesome-codex-skills 令 Codex 由「寫 Code」變成「做嘢」嘅關鍵工具包

完成

玄學自媒體神器！這個 AI Agent 自動算八字、解紫微，內容標準化又專業

AI 命理工具 MingLi-Bench：自動算八字解紫微，內容標準化又專業

完成

豆包都開始收費了...分享我的常用AI工具箱

作者因豆包收費而分享自己喺唔同場景用嘅AI工具箱，強調按需選用，冇一招通吃。

完成

發現一個寶藏工具：openclaw換模型，終於不用手改配置了！

CC Switch 神器：界面化切換模型，唔使再手改配置

完成

幻覺減半，廢話砍三成！被罵一年，OpenAI 終於把 ChatGPT 改對了

GPT-5.5 Instant 上線：幻覺減半、廢話少三成，ChatGPT 日常模型大改進

完成

用不上 Claude Design？我找到了一個免費開源的本地平替

Open Design 係 Claude Design 嘅免費開源本地替代方案，門檻低，效果合格。

完成

最值得收藏的 DESIGN.md 工具合集｜6 個最佳網站，讓 AI 做 UI 更高效

6個最佳DESIGN.md工具推薦，助你高效用AI做UI

完成

五一我沒開電腦，但我的 Agent 團隊沒放假 | 如何用Hermes Agent移動辦公

手機指揮 Agent 團隊：五一唔開電腦，內容系統依然運行

完成

企微的這些新功能，補齊了AI在你公司的最後一公里

企業微信新功能點樣系統性補齊AI落地嘅context黑洞

完成

一張圖生成一個實時回應你的對話視頻角色 Runway 讓視頻生成走進了對話現場

一張參考圖生成實時對話視頻角色，Runway Characters 將視頻生成推向對話場景

完成

看完這份Claude code Skill的官方規範，我把 8 個 Skill 全重構了

Claude Code Skill嘅關鍵唔係指令內容，而係description同fork模式，掌握呢兩個設計原則先發揮到真正威力。

完成

高效獲取投行研報：深入解析 Webhook 自動化運行機制

Webhook 事件驅動：自動化投研情報系統嘅核心通信樞紐

完成

理解

理解不是定義，係腦入面一團「雲」嘅形狀；橫向相似度同縱向抽象度決定理解嘅廣度與深度。

完成

三年，AI從我的對話玩具進化為全能工作助理

三年來，AI 從對話玩具進化到全能工作助理，關鍵係從指令走到意圖理解，再到全面接管工作流，但人類嘅判斷力反而可能被削弱。

完成

我把提示詞優化工具重寫了一遍：VADPS 2.0

提示詞框架VADPS升級到2.0，從「動詞驅動流程」轉向「結果優先評分」，更適合GPT-5.5等新一代模型，強調定義目標、成功標準、限制與停止規則，而非列滿步驟。

完成

黑白線稿一鍵出圖，一句話生成品牌視覺（開源附教程）

黑白線稿品牌視覺一鍵生成：editorial-line-system 技能實測與教學

完成

從夯爆到夯，鋭評 7 個最主流的 AI 編程模型！

關注公眾號，AI 技術乾貨及時送達↓推薦閲讀：OpenAI 把 Codex 裝進了 Claude Code！！大家好，我是R哥。最近 AI 編程模型又卷瘋了。一邊是國外大模型繼續往工程能力、長上下文、Agent 方向猛衝，另一邊是國產模型也開始發力，各種大模型宣稱能媲美 Claude 的能力。。所以現在再問哪個編程模型最強，其實已經不太好回答了，因為不同模型的性格差異越來越明顯了。有的適合寫複雜工程，有的適合做 UI，有的適合改老項目，有的適合跑 Agent，有的 benchmark 很漂亮，但真正幹活的時候可能又是另外一個樣子。我這篇就不做學術排名了，只聊真實編程體感。。第一梯隊（夯爆）第一梯隊我覺得就是兩個：GPT 5.5 和 Claude Opus 4.6 / 4.7，毫無疑問，這兩個基本屬於雙王並列。沒有絕對第一，只有場景適配。GPT 5.5 的優勢是綜合、全面，工程場景也很穩。尤其是 API 生態、工具鏈適配、工程落地這一塊，搭配 Codex CLI、Codex APP、雲端支持，這一套確實成熟，它可能不是最牛逼的，但是全方面能力最強的。而且 GPT 5.5 的性價比也很能打，如果你是高頻使用，比如每天寫文案、寫代碼、生成圖片等工作，Plus 就完全能夠勝任，它屬於那種量大管飽型選手。當然，它缺點也有。它寫界面的審美還需要繼續打磨，功能上能完成，但 UI 有時候會有點程序員審美，能用，規整，但少一點產品感和高級感。Claude Opus 4.6 / 4.7 則是另一種強。它的上下文理解很強（1M），尤其適合產品邏輯、複雜需求、長文檔、UI 交互這類任務。在實際編程時，你都不用把每個細節都說死，它能順着你的意圖往下補，甚至能提前想到一些你沒說但確實需要的東西。這就是 Claude 最厲害的地方，它不是隻會寫代碼，它更像懂產品的人在幫你寫代碼。缺點就是：貴、對網絡環境要求非常高、非常容易封號，前陣子又搞出了實名認證，用 Claude 的成本是越來越高，也越來越不可控。參考閲讀：• 炸了！Claude Code 移除 Pro 用戶！！• 喪心病狂！Claude 開始要求實名身份驗證了。。。就 Claude 種種變態的限制行為，建議大家還是還是不要作為首選或者太依賴它。第二梯隊（夯）第二梯隊也很有意思，比如：GLM-5.1、Gemini 3、Qwen 3、DeepSeek V4、Kimi K2.6 這些大模型就在這一檔。先說 GLM-5.1，目前最接近第一梯隊的國產模型之一。尤其是 Agent 能力，已經能貼着第一梯隊打了。它不是那種只會回答問題的聊天模型，而是已經開始具備拆任務、調工具、持續推進的高級能力。但它的問題也明顯：慢，而且不夠穩定，算力不夠，訂閲非常難，Coding Plan 基本都要靠搶。再說說 Gemini 3，它是典型的偏科生。它在 UI 和前端場景挺能打，尤其是頁面佈局、視覺表達、交互結構，經常能給你一些不錯的結果。做頁面時，它有時候比傳統工程型模型更有感覺。但工程場景偏弱，比如：複雜後端、長鏈路重構、多模塊項目協同，它沒有 GPT 和 Claude 那麼穩。所以 Gemini 的定位很清楚，適合前端、UI、視覺類任務，複雜工程儘量別用它。再說說通義千問 Qwen 3，它屬於國產裏非常能打的一檔。它的整體能力比較均衡，一般來說在代碼生成、中文理解、工程任務上表現都比較穩定，比如寫接口、補代碼、做業務邏輯這類活都能很好勝任。而且它的優勢在於生態完整 + 落地能力強，依託阿里雲，在企業應用、API 接入、私有化部署等場景裏會更有優勢。但問題也有，一般來說在複雜工程推理、長上下文深度理解上，和第一梯隊還是有差距。另外，它也是一樣的套路，Coding Plan 基礎款已經下線，高級套餐訂閲還要靠搶。。再說說 DeepSeek V4，它寫代碼比較穩重。很多模型寫代碼喜歡加戲，明明你只要改一個地方，它順手給你重構一大片。DeepSeek 的風格一般更收斂，常規業務代碼寫得快，也不太亂髮揮。它適合程序員日常開發裏的大量基礎活，比如 CRUD、腳本、接口邏輯、工具類、常見算法，它都挺穩。但它的問題是，目前沒有 Coding Plan，如果拿來高頻編程，成本會顯得有點高。最後再說說 Kimi K2.6，它屬於潛力型選手。它的 benchmark 很出色，Coding Plan 也不用搶，但實際用下來，體感有時沒那麼絲滑，尤其是複雜工程任務裏，它有時會在執行過程中掉一下鏈子。感覺它很適合龍蝦這麼類 Agent，之前還上過最適合 OpenClaw 大模型的榜單。所以我對 Kimi 的評價是，上限很高，但穩定性還需要時間。怎麼選？我建議別隻用一個模型，而是更合理的組合使用：• 寫後端、修 bug、處理工程任務，用 GPT 5.5。• 做複雜產品設計、需求梳理，用 Claude 4.7。• 做前端頁面和視覺草稿，可以讓 Gemini 3 先跑一版。• 想體驗國產大模型能力，可以試 GLM-5.1、Qwen 3。• 想寫穩定業務代碼，可以用 DeepSeek V4。組合搭配，這樣才是目前更實際的玩法，我目前也是這麼玩的。因為模型之間已經不是簡單的誰強誰弱，而是各方面能力各不不同，就像團隊裏有人適合做架構，有人適合寫頁面，有人適合修線上問題，有人適合寫文檔。你非要讓一個大模型幹所有活，也不是不行，就是效率、質量等方面可能不一定是最高的。當然，也可以根據自己的任務進行測試，一般簡單的任務你隨便用哪個可能區別都不大，複雜任務還得是用最專業的、最夯的模型。好了，今天就暫時分享到這裏了，R哥持續分享更多 AI 好玩的東西，公眾號第一時間推送，關注「AI技術宅」公眾號和我一起學 AI。⚠️ 版權聲明：本文系公眾號 "AI技術宅" 原創，未經授權禁止轉載，嚴禁搬運、抄襲、洗稿、侵權一律投訴，並保留追究其法律責任的權利。 < END >推薦閲讀：OpenClaw 在國內的熱度徹底涼了。。OpenClaw 必裝的 10 個 Skills！！OpenClaw 飛書 + QQ 接入完整指南！！Claude Skills 徹底爆了，從實現原理到實戰！開源版 Claude Code 殺瘋了，怒斬 70k+ Star！Gemini CLI 免費用戶也能使用 Gemini 3 了！免費白嫖 Gemini 3 Pro 的 3 種方式，太香了！Gemini 3 Pro 的 8 個官方入口（建議收藏）玩轉 CodeX CLI 的 16 個實用小技巧！玩轉 Claude Code 的 23 個實用小技巧！更多 ↓↓↓ 關注公眾號 ✔ 標星⭐ 哦

完成

AI知識庫不該只會收藏：我想打造一個能自動加工的AI知識庫，把 Dan Koe 和 LLM Wiki 合成 AIWiki

MaxKing寶藏全棧開發者 × 量化交易 × AI 重度用戶。這裏記錄我用 AI 提升效率、解決問題、優化流程的真實實踐，也分享工具背後的判斷、踩坑和可複用方法。AIWiki · 個人知識工廠 03前兩篇寫完後，我反而更確定了一件事：我真正想做的，不是一個普通知識庫。第一篇我講的是收藏吃灰的問題。很多人收藏了大量文章、連結、筆記、教程，但真正要寫文章、做方案、整理思路時，還是要從零開始。【為什麼你收藏了那麼多文章，最後還是寫不出來想要的文章？你要打造自己的個人知識工廠】第二篇我講的是 Karpathy 提出的 LLM Wiki。它給我的啓發是：知識庫不應該只是資料堆，也不應該每次都靠 RAG 臨時翻資料、拼答案，而應該讓 AI 持續把資料讀懂、拆解、整理、更新，形成一個不斷生長的 Wiki。【Karpathy 的 LLM Wiki 給了我一個啓發：知識庫不該只是收藏夾，而是加工成可調用、可維護、可產出的內容資產，提寫作和內容創作效率】但到這裏，我發現還差最後一塊。知識沉澱之後，到底怎麼變成內容產出？如果一個知識庫只是越來越完整，但不能幫我寫文章、做選題、產出方案，那它仍然離我的真實工作流有一段距離。所以，我開始想：有沒有可能把這兩條線合在一起？01-MaxKing.cc-Dan Koe 讓我重新理解了內容創作Dan Koe 給我的啓發，不是某個具體模板，而是一種內容生產的思路。很多人以為，持續輸出靠的是靈感。今天有靈感，就寫一篇；明天沒靈感，就斷更。看到好文章就收藏，看到好觀點就記下來，期待未來某一天能用上。但真正到了要寫的時候，還是打開空白文檔，從標題開始重新想。每次創作都像重新開工：重新找資料，重新想角度，重新設計結構，重新找案例，重新組織表達，重新說服自己這篇文章值得寫。不是因為沒有輸入，而是輸入沒有變成可複用資產。一篇文章如果只是被收藏，它還是別人的文章。只有當它被拆出來，變成觀點、鈎子、結構、案例、金句、轉化弧、選題和大綱，它才開始變成你的素材。我現在越來越覺得，內容創作不是從空白頁開始，而是從素材庫里長出來。Dan Koe 這條線解決的是：內容如何持續輸出。02-MaxKing.cc-LLM Wiki 讓我看到知識沉澱的另一種方式但只解決內容輸出還不夠。如果所有素材只是散落在一堆文檔裏，時間久了，還是會亂。這時候，Karpathy 的 LLM Wiki 給了我另一個啓發：知識庫不應該只是臨時檢索資料，而應該被 AI 持續編譯和維護。傳統 RAG 更像“臨時翻書”。你問一個問題，系統去資料堆裏找相關片段，然後臨時拼出一個答案。這當然有用。但問題是，這次回答結束之後，知識有沒有真正沉澱？下次再問類似問題時，是不是還要重新檢索、重新拼接、重新組織？LLM Wiki 的思路不一樣。它不是每次都臨時找答案，而是在資料進入系統時，就開始做整理：保留原文、提取概念、更新頁面、建立關聯，把原始資料變成可維護的 Wiki。這樣，知識不是問的時候才被臨時拼出來，而是在平時就被持續整理、更新和沉澱。LLM Wiki 這條線解決的是：知識如何長期沉澱。03-MaxKing.cc-一個偏輸出，一個偏沉澱，但單獨看都不完整這兩條線單獨看都很有價值。但我越想越覺得，單獨做其中一個，都不夠完整。如果只學 Dan Koe 的內容系統，我會更重視選題、表達、內容資產、寫作結構。但這些素材如何長期沉澱？如何更新？如何關聯？如何避免越積越亂？這仍然是問題。如果只做 LLM Wiki，我可能會得到一個更好的知識系統。它能保存原文、整理概念、更新 Wiki、建立知識關聯。但這些知識如何變成選題、文章、公眾號內容、視頻腳本、項目方案？這條輸出鏈路還不夠直接。我理解的兩條線Dan Koe解決內容資產、持續輸出、選題和表達的問題。LLM Wiki解決知識沉澱、持續維護、結構化 Wiki 的問題。AIWiki要把資料變成知識資產，再讓知識資產持續服務內容產出。所以我不想只做一個能存資料的知識庫，也不想只做一個寫作素材庫。我想要的是二者之間的閉環。04-MaxKing.cc-所以我想把它們合成 AIWiki這就是 AIWiki 的定位。它不是普通 Obsidian 模板，不是提示詞合集，不是另一個收藏夾，也不是單純的 RAG 知識庫。我想做的是：把資料加工成知識資產，再讓這些知識資產持續服務內容產出。一篇文章或一個連結進入 AIWiki 後，不應該只是被保存。它應該經歷一輪加工：先保留原文，再生成資料卡，再提取關鍵觀點，再沉澱到相關知識頁面，再拆出創意積木，再生成可寫選題，再生成文章大綱，最後支撐內容產出。文章 / 連結↓Raw 原文歸檔↓Source Card 資料卡↓Wiki 知識沉澱↓Creative Assets 創意積木↓Topics 選題 / Outline 大綱↓內容產出 / 反饋迴流這才是我理解的個人知識工廠。不是資料進來就結束，而是資料進來後，要繼續被拆、被連、被用、被複盤。05-MaxKing.cc-AIWiki 的核心是加工，而不是收藏我現在越來越覺得，知識庫最容易被誤解的地方，就是大家太關注“存”。存在哪裏？怎麼分類？怎麼打標籤？用 Notion 還是 Obsidian？要不要雙鏈？要不要圖譜？這些都重要，但它們不是最核心的問題。真正核心的問題是：這條資料最後有沒有被用起來？一條資料進入 AIWiki 後，至少應該變成一個知識頁面、一張資料卡、一個創意積木、一個選題、一份文章大綱，或者一篇內容。如果它什麼都沒有變成，只是靜靜躺在文件夾裏，那它和普通收藏沒有本質區別。06-MaxKing.cc-第一版只解決一件事AIWiki 後面當然可以做很多事情。比如自動收集資料、批量處理連結、接入飛書羣、接入微信和 Discord、接入 OpenClaw / QClaw、做團隊知識流。但第一版我不想一上來做大而全。第一版只解決一件事：把一篇資料加工好。用戶手動給一篇文章或一個連結。AIWiki 能自動生成原文歸檔、Source Card、創意積木、選題和文章大綱。這一件事先跑通。如果一篇資料都加工不好，批量只會批量製造垃圾。所以第一版要剋制。先把最小閉環跑起來。07-MaxKing.cc-下一篇，我會把流程圖畫出來到這裏，AIWiki 的定位就清楚了。Dan Koe 解決輸出。LLM Wiki 解決沉澱。AIWiki 要做的是把二者連成一條工作流。這條工作流不是為了讓收藏夾更大，而是為了讓資料真正變成可沉澱的知識、可複用的積木、可延展的選題、可寫作的大綱、可發佈的內容。下一篇，我會把整個 AIWiki 的流程圖畫出來。一篇文章或一個連結，如何從 Raw 原文歸檔，變成 Source Card 資料卡，再變成創意積木、選題和文章大綱，最後進入內容產出和迴流。如果你也想看這套系統怎麼搭，可以關注公眾號，回覆：AIWiki我會繼續整理《AIWiki 個人知識工廠流程圖》，也會在羣裏同步最新開發進度。AIWiKi永久免費下一篇預告AIWiki 個人知識工廠流程圖：一篇文章如何變成內容資產？- END -關於 MaxKing寶藏我是 MaxKing，全棧開發者、量化交易實踐者，也是 AI 重度用戶。這裏分享的不是遙遠概念，而是我在真實使用、搭建和踩坑後留下的判斷。如果這篇文章對你有啓發，歡迎點贊、在看、轉發，也歡迎加我好友交流 AI 工具和自動化實踐。

完成

AI正在“殺死”這些崗位，但也在悄悄創造新機會

AI正在“殺死”這些崗位，但也在悄悄創造新機會第015篇01 一個讓數百萬人失眠的問題“我的工作會被AI取代嗎？”這個問題，過去三個月，我被問了不下50次。問的人來自各行各業：設計師、翻譯、文案、程序員、會計、教師、甚至還有一位三甲醫院的放射科醫生。我沒有標準答案。但我花了整整兩週時間，做了一件笨事：我把20多份國內外權威機構關於“AI對就業影響”的報告——OpenAI、高盛、麥肯錫、世界經濟論壇、微軟研究院、中國信通院——全部翻了一遍，然後把關鍵數據和結論餵給AI鏡子，讓它幫我提煉出普通人最應該知道的3個深層真相。今天，我把這3個真相徹底展開。不販賣焦慮，只給可操作的出路。02 真相一：AI不是取代“崗位”，而是吃掉“任務”這是最關鍵、也最容易被誤解的一點。大多數人想象AI會像工業革命那樣，直接消滅一整類職業。比如汽車消滅了馬車伕，數碼相機消滅了膠捲廠。但AI的“吃法”完全不同。它正在做的是：把每個崗位拆解成幾十個任務，然後吃掉那些重複、可標準化、可預測的任務。以插畫師為例。一個商業插畫師一天的工作包含：· 接聽客戶需求電話（需要共情、理解模糊描述）· 頭腦風暴創意方向（需要聯想、審美判斷）· 畫初步草圖（AI可完成70%）· 細化線稿（AI可完成50%）· 上色、調光影（AI可完成80%）· 根據客戶反饋修改（需要溝通、理解）· 交付文件、處理發票（可自動化）AI能替代的是“畫草圖”“上色”“線稿”這類執行任務，替代率50%-80%。但“理解客戶沒說出來的需求”“判斷創意方向好不好”“安撫暴躁的甲方”這些任務，AI替代率接近於零。所以真相是：AI不會讓插畫師失業，但會讓“只會畫圖、不會溝通”的插畫師失業。被淘汰的不是崗位，而是單一技能者。那些同時具備“溝通+審美+執行”的插畫師，反而因為效率提升而更有競爭力。03 真相二：“崗位任務替代率”以下是我綜合多份報告整理的崗位分析，按風險從高到低排列：【極高風險崗】崗位：數據錄入員基礎任務替代率：90%以上核心不可替代能力：幾乎沒有說明：這類工作的核心就是重複，AI幾乎完美覆蓋。【高風險崗】崗位：客服（基礎問答）基礎任務替代率：約70%核心不可替代能力：複雜投訴處理、情緒安撫崗位：翻譯（筆譯）基礎任務替代率：60%-80%核心不可替代能力：文化適配、專業術語判斷、情感語氣【中高風險崗】崗位：會計（記賬報税）基礎任務替代率：60%-80%核心不可替代能力：税務籌劃、風險判斷崗位：設計師（平面）基礎任務替代率：40%-60%核心不可替代能力：品牌語言、創意概念、客戶溝通【中等風險崗】崗位：文案（產品說明）基礎任務替代率：50%-70%核心不可替代能力：品牌策略、創意洞察崗位：放射科醫生（讀片）基礎任務替代率：30%-50%核心不可替代能力：臨牀綜合判斷、患者溝通【中低風險崗】崗位：程序員（寫代碼）基礎任務替代率：30%-50%核心不可替代能力：系統架構、需求分析、調試崗位：翻譯（口譯）基礎任務替代率：20%-30%核心不可替代能力：現場應變、文化默契、語氣把控【低風險崗】崗位：教師（知識講授）基礎任務替代率：30%-50%核心不可替代能力：情感激勵、個性化引導關鍵結論：任何崗位只要核心是“重複已知模式”，就會被AI替代；只要核心是“不確定條件下的人性判斷”，就安全。04 三個真實行業，AI已經悄悄動手了案例一：翻譯行業——兩極分化正在發生某頭部翻譯公司內部數據顯示：2024年起，基礎筆譯訂單量下降40%，單價腰斬。但同時，高端“本地化+文化適配”訂單量上漲30%，單價翻倍。一位從業8年的自由譯者告訴我：“以前接200元/千字的活，現在沒了。但2000元/千字的活，反而更多了——客戶要的不是翻譯，是‘讓外國讀者看完會笑’。”案例二：客服行業——人機協同成標配某電商平台披露，AI處理了70%的常見諮詢（“什麼時候發貨”“怎麼退換貨”）。但客服團隊人數沒減，反而增加了——因為他們現在專門處理“快遞丟了客戶情緒崩潰”“商品描述歧義引發投訴升級”。一位客服主管說：“AI可以回答問題，但解決不了情緒。而情緒，才是最難搞的部分。”案例三：編程行業——AI讓初級程序員更難GitHub Copilot等工具已經能生成大量基礎代碼。某互聯網公司技術總監坦言：“我們以前招實習生寫CRUD，現在AI就能做。但我們非常缺‘能把業務需求翻譯成技術方案’的人。”他說，現在他們招人更看重“系統思維”和“溝通能力”，而不是“刷LeetCode”。05 真相三：AI正在創造的新崗位，你知道幾個？每一次技術革命都如此：消滅舊崗位，創造新崗位。AI創造的新崗位，並不需要你懂代碼。以下5個方向正在招聘：【1】提示詞工程師 / Prompt Engineer工作內容：設計能讓AI輸出高質量結果的指令。所需能力：邏輯清晰、懂行業術語、會分層拆解問題。薪資：國內一線城市15k-30k/月。入門路徑：免費學習OpenAI的Prompt工程指南（中文版），自己搭個ChatGPT練手，然後接個閒魚小單證明能力。【2】AI內容審核師 / AI Content Reviewer工作內容：檢查AI生成的內容是否準確、安全、符合品牌調性。所需能力：細心、領域知識、判斷力。薪資：8k-15k/月。不少AI公司正在遠程招聘這類崗位，適合作為兼職。【3】AI訓練數據標註員 / Data Labeler工作內容：為AI提供“標準答案”，比如圈出圖片裏的車輛、標註對話中的情緒。所需能力：耐心、視力好。薪資：按量計酬，時薪20-40元。門檻極低，適合學生、寶媽、兼職。【4】人機協作流程設計師 / Human-AI Workflow Designer工作內容：幫助企業梳理“哪些任務交給AI、哪些留給人”，並設計高效協作流程。所需能力：流程思維、溝通能力、懂業務。薪資：20k-40k/月（通常是諮詢公司或大廠內部轉型崗）。這可能是未來5年最緊缺的管理崗位。【5】AI應用培訓師 / AI Adoption Trainer工作內容：教普通人或企業員工如何使用AI工具提升效率。所需能力：教學能力、AI工具實操經驗。變現方式：企業內訓（3000-10000元/天）、線上小課（99-499元/人）。我認識的一位自由職業者，靠教律師用AI，月入3萬+。這些崗位都不要求你是計算機專業，但要求你：既懂AI的能力邊界，又懂具體行業的需求痛點。06 普通人現在能做的4件事第一：用AI鏡子做一次“任務顆粒度盤點”拿出紙筆，把你每週工作的任務列到第三級。例如“寫週報”可以拆成：①收集本週工作記錄 → ②挑選3個亮點 → ③找對應數據 → ④組織語言 → ⑤調整格式 → ⑥發給領導。然後逐項問AI：“這項任務，AI能幫我完成什麼程度？需要我做什麼？”你會發現，大部分“執行動作”都能AI化，只有“判斷、決策、人際”需要你。第二：選一個AI新崗位，投入20小時刻意練習就選“提示詞工程師”。不要報課。搜“OpenAI Prompt Engineering Guide”，看免費英文原版或中文翻譯。然後自己在DeepSeek/Claude上練，寫出10個高質量的Prompt。接着去閒魚掛“代寫AI提示詞”服務，定價10-50元/個。接到單子後，你會在真實反饋中快速成長。20小時，足夠讓你超越90%的票友。第三：在你所在的公司/行業，成為“那個懂AI的人”不需要成為專家。你只需要：每週嘗試用一個AI工具完成一件日常工作，然後記錄“原本用時 vs AI用時、質量差異、需要注意的坑”。開會時不經意提一句：“我試了下，這個月報如果用AI先跑一遍，能省2小時。”老闆會覺得你有想法、有執行力。這比任何PPT都管用。第四：用“免費清單”驗證需求，再決定深耕像我第14篇做的：提供一份免費《AI輔導孩子作業的5個Prompt》，測試留言數量。你也可以做一份《AI寫郵件的5個模板》《AI做PPT的3個框架》等等。有人要，說明有需求；沒人要，換方向。成本幾乎為零。07 你的任務清單（本週可完成）· 週一：列一個自己工作任務的清單（至少10項）· 週二：拿其中5項去問AI，寫出替代建議·週三：花2小時學習Prompt Engineering基礎· 週四：寫5個Prompt，發給朋友測試· 週五：在閒魚掛一個服務（比如“代寫週報Prompt”）· 週末：覆盤一週的收穫，寫下3條經驗08 最後，我想聽聽你的真話這篇文章很長，謝謝你看到這裏。現在，我想問你一個扎心但重要的問題：你的工作裏，哪一部分是AI目前絕對替代不了的？在評論區寫下來。哪怕答案是“老闆讓我改版8次，AI不會崩潰”。這不是為了尷尬，是為了讓你記住：AI能替代任務，替代不了你身上那些真實、鮮活、甚至有點擰巴的部分。評論區抽3位朋友，送一份我整理的《AI崗位轉型資料包》（包含提示詞工程指南+新崗位招聘信息彙總）。——來自 ai隨記的第十五天

完成

【真實故事】從實體租賃業務的痛點出發：打造年經常性收入突破一千五百萬的SaaS帝國

Roy van den Broek在16歲時創立了一家視聽租賃公司，並對當時可用的軟件感到沮喪。於是，他構建了自己的軟件。現在，Rentman 正向着 2000 萬經常性年收入邁進。以下是Roy講述他的創業故事。邁向2000萬年收入的征程我是Roy。我的背景是活動服務和視聽製作，因此我在現場活動的運營方面花費了大量時間。正是在那裏，我發現了問題。行業正在使用的工具要麼是靠膠帶粘合的電子表格，要麼是為其他行業構建、然後強行適配我們行業的軟件。如今，我正在構建 Rentman，這是一個面向活動和媒體行業的運營平台。它處理運營製作公司的混亂中游環節，包括設備租賃、人員調度、報價、物流和開具發票。我們的目標是為該領域的企業提供一套貼合其工作方式的系統，而不是使用五款勉強能用的工具。我們服務於租賃和製作公司，涵蓋視聽、燈光、舞台搭建、廣播和電影領域。這適用於任何需要設備和人員在正確的時間出現在正確的地點的場景。我們目前的經常性年收入在 1500 萬到 2000 萬之間。修復破碎的系統我從12歲開始做 DJ，到16歲時，我已經擁有了自己的視聽租賃公司。在運營過程中，我反覆遇到同樣的障礙，我們使用的軟件要麼是為其他行業構建的，要麼是昂貴的、笨重的本地部署軟件，沒人喜歡。大家都抱怨，但沒人更好的選擇。所以，我為自己的公司構建了工具。這是我唯一的目標。我不是試圖創業或銷售軟件，而是為了解決一個問題，享受構建過程，感覺很自然。其他租賃公司聽說了這事，也想使用。其中五家公司非常喜歡它，在早期支持了這想法。但即便那時，我認為這只是一個一次性項目，構建它，發佈它，然後回去租揚聲器。機會慢慢變得清晰。人們不斷要求更多，產品也在不斷增長。最終，很明顯這比我自己的租賃公司更大。這就是 Rentman 如何變成 Rentman 的。但起點不是野心，我只是想修復對我來說破碎的東西。沒有宏大計劃我沒有宏大的計劃。沒有路線圖，沒有團隊，沒有融資演講稿。我只是根據自己的運營中遇到的問題來構建功能。這成了一個巨大的優勢。我確切知道哪些功能重要，因為我每天都在使用它們，包括設備可用性、報價、人員調度和項目規劃。我不需要猜測租賃公司需要什麼，我就是其中之一。一旦其他公司開始使用它，工作量超出了我個人能處理的範圍。我聘請程序員來幫忙。我們保持緊湊的反饋循環，我與租賃公司交談，我們構建、發佈並迭代。早期支持的五家公司是我們的首批設計合作伙伴。他們告訴我們哪裏壞了，缺什麼，以及什麼不符合他們的工作流。兩條原則從第一天起就塑造了產品。一是簡潔性，因為現有工具過於複雜，沒人喜歡用。二是雲端化，因為行業希望隨時隨地工作，而當時的軟件迫使他們坐在辦公桌前。我們是荷蘭最早的一批基於雲的租賃工具之一，這成了它傳播的重要原因。技術棧在後端，我們主要使用現代 PHP，使用 MySQL 作為主數據庫，MongoDB 用於特定的微服務，全部運行在 AWS 上。在前端，我們使用帶有 TypeScript 的 Angular。在基礎設施方面，我們嚴重依賴 AWS，包括 RDS、S3、CloudFront 等常規服務。八年的自力更生我們是一家 SaaS 企業。我們有多種產品，每種產品都有各自的按席位訂閲模式。客戶挑選他們需要的產品，併為每個產品按用戶付費。頭八年，我們完全是自力更生。沒有風險投資或外部資金。在獲得外部資本之前，我們已經在 70 多個國家擁有了數萬名用戶。正因為如此，我自己始終是最大的挑戰。自力更生意味着隨着公司的發展，我扮演了每一個角色。我開始是開發人員，然後做銷售，接着處理招聘，然後學習如何領導團隊，如何成為首席執行官。這些都是我在飛行中學習的不同工作。每當公司進入新階段，我的適應速度就成了瓶頸。產品可以擴展，市場在那裏，團隊也準備好了，但我需要成長以適應角色的下一個版本。這需要時間、犯錯和大量的“忘卻學習”。如果能更快地完成這些過渡，我們今天會更大。一個簡單的增長飛輪增長大多是有機的。以下是我們在獲得融資前的主要渠道。首先是社區。視聽和活動製作界聯繫緊密。人們相互合作，在貿易展上見面，互相推薦工作。我們在這個圈子裏沉浸多年，不是作為軟件供應商，而是作為其中的一員。我們參加行業活動、舉辦網絡研討會、贊助活動，並與用戶保持真實的對話。當一家制作公司向另一家推薦 Rentman 時，這比我們能買到的任何東西都更有價值。其次是口碑在這個行業的複合效應。自由職業人員為多家租賃公司工作。當某人在一個項目中學會了 Rentman，他們希望下一位僱主也使用它。這是一個我們賴以生存的自然飛輪。第三是產品驅動的增長。任何人都可以開始免費試用，建立自己的賬户，並在一天內運行真實的項目。我們在引導、文檔和確保首次體驗順暢方面投入了大量資金。我們的大多數客戶是自己找到我們，試用，然後自己做決定。銷售是後續跟進，是為了提供幫助，而不是為了推銷。第四，客戶反饋作為增長引擎。每一個功能請求、每一張支持工單、每一次用戶訪談都滋養着路線圖。當客戶看到產品圍繞他們的需求演進時，他們會停留更久，使用更多，並告訴其他人。留存和增購是 SaaS 增長的靜默引擎，我們對此非常重視。這個飛輪很簡單，構建行業真正想要的東西，讓試用變得容易，讓用戶自行上手，保持產品足夠好，讓他們留下來並帶來其他人。組建團隊的挑戰將團隊從幾個人發展到 100 多人是一個巨大的挑戰。在 10 人時有效的方法在 50 人時行不通，在 50 人時有效的方法在 100 人時也行不通。自力更生讓它更難，因為我們負擔不起過度招聘。我們必須從收入中賺得每一位新的領導者和管理結構。《Scaling Up》一書為我們提供了很好的框架和指導，我推薦它。為你所愛之事構建這是我的建議，做你喜歡的事。不是你認為能賺錢的事，不是演講稿裏聽起來不錯的事，也不是時髦的事。而是你真正喜歡鑽研的事情。因為這會很難很長一段時間，任何其他動力都會在在公司倒閉前耗盡。如果結果不盡如人意，至少你在嘗試的過程中獲得了樂趣。後續計劃首先是拿下美國市場。我們在該類別中是全球市場領導者，但仍有很大的增長空間，特別是在美國。其次是人工智能。世界變化很快，我要確保將其轉化為用戶的優勢，而不是對我們業務的威脅。我們有機會重新思考運營軟件的工作方式。環內人工智能可以極大地改善客戶今天所做的很多事情，包括規劃、報價和協調。如果我們做好了這一點，我們不僅改進了產品，還改變了產品本身的定義。這可能意味着顛覆我們自己。我們當前的商業模式可能不適合 AI 原生產品。按席位定價、打包方式、價值交付，所有這些都擺在桌面上。我寧願殺死我們自己的模式並構建下一個，也不願固守已有成果，讓別人來對我們做同樣的事。本文圖片來自網絡，如有侵權，請聯繫我們刪除THE END我是黃永光資深商業空間運營管理專家，擁有23年泛家居行業全鏈路管理經驗。作為兼具戰略視野與落地能力的複合型管理者，曾帶領企業實現從千萬級到億元級營收跨越，助推兩家行業標杆企業躋身中國室內設計百強機構。我認為技術革命的核心價值，不在於物理世界的簡單改造，而在於重構人類認知與創新的底層邏輯。每個人都有潛力成為創業者，每個行業都值得利用人工智能重新做一遍。

完成

文章庫

AI知識庫不是資料倉庫：從文章連結到選題和大綱的工作流拆解

全網首發，無限，seedance2.0一直用，AI視頻，還能用其他AI視頻/AI圖片主流模型，小白全能創作神器。

我把DeepSeek的技術報告做成了科普視頻

從知識庫到神經系統：企業大腦的第三層

AI視頻工具悄悄走到了第三階段

Claude Code、Codex 的正確用法，是 Goal-Driven

Hermes 比 OpenClaw 慢10倍，為什麼還有人用？

OpenSpec + Superpowers：一個管寫什麼，一個管怎麼做，6 步實現 AI 規格驅動 TDD 開發（實戰版）

OpenSepc新版本新提升