Back to Details

small-business-ai-transformation

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Small Business AI Transformation

小型企业AI转型方案

When to Use

适用场景

  • User wants to help a real small service business with AI (family business, friend's business, etc.)
  • Owners are non-technical — phone-driven, no CRM, no dashboards
  • Goal: build an AI "front-office employee" that finds leads, qualifies them, estimates jobs, books, bills, and reports
  • Also applies when a hackathon concept needs a real-world customer story (not AI-for-AI-people)
  • 用户希望为真实的小型服务企业（家族企业、朋友的企业等）提供AI支持
  • 企业主不懂技术——依赖电话沟通，没有CRM系统，没有数据仪表盘
  • 目标：打造一个AI「前台员工」，负责获客、客户资质审核、报价、预约、账单处理及报表生成
  • 也适用于黑客松项目需要真实客户案例的场景（而非面向AI从业者的AI方案）

Core Principle: The Agent is an Employee, Not a Tool

核心原则：Agent是员工，而非工具

The framing matters for both the business owners AND for hackathon judges. A tool requires someone to operate it. An employee works 24/7 and reports by text. The owners don't log into anything. They text. The agent handles the rest.
The demo moment that wins: "My 62-year-old mom texts an AI agent to run her business. She doesn't know what an API is."
这种定位对企业主和黑客松评委都至关重要。工具需要人来操作，而员工可以全天候工作并通过短信汇报。企业主无需登录任何系统，只需发送短信，剩下的由Agent处理。
制胜演示时刻：「我62岁的妈妈通过短信让AI Agent运营她的企业，她甚至不知道API是什么。」

Methodology: 6 Steps

实施方法：6个步骤

Step 1: Website Audit (Browser Tools)

步骤1：网站审计（浏览器工具）

Navigate the full site systematically: Home → Services → Testimonials → FAQ → Blog → Contact. For each page, note:
  • Broken pages (404s, dead links) — common in old WordPress sites built by contractors
  • Stale content (blog last updated >1 year ago, copyright date)
  • Missing features (no online estimator, no chat, no booking, no online payment)
  • Mobile experience (does it render on phone?)
  • SEO gaps (no geo-targeted content for service areas, no fresh content)
  • Contact form (does it actually work? does it have reCAPTCHA? what fields does it collect?)
Record findings in the North Star wiki page (Step 5).
系统性浏览整个网站：首页→服务→客户评价→常见问题→博客→联系我们。针对每个页面，记录：
  • 页面故障（404错误、无效链接）——这类问题在承包商搭建的老旧WordPress网站中很常见
  • 内容过时（博客超过1年未更新、版权日期陈旧）
  • 功能缺失（无在线报价工具、无聊天功能、无预约系统、无在线支付）
  • 移动端体验（在手机上能否正常显示？）
  • SEO漏洞（无针对服务区域的地理定位内容、无新鲜内容）
  • 联系表单（是否可用？是否有reCAPTCHA验证？收集哪些字段？）
将发现记录在步骤5的North Star维基页面中。

Step 2: Business Model Discovery (Ask the User OR Analyze Their Data)

步骤2：商业模式调研（询问用户或分析数据）

Option A — Ask the user (when no financial data is available):
Ask these questions to the user (who talks to the business owners). Get rough numbers — precision isn't needed for concept development:
  1. Who runs it? Owners, roles, who does what (ops vs marketing vs field)
  2. Volume & pricing — Jobs per month, average job cost, pricing model (sqft? flat rate? tiers?)
  3. Lead sources — Where do customers come from today? Rough percentage split (realtors, Google, referrals, insurance, etc.)
  4. Revenue channel risk — Is 80% of revenue from one source? What happens when that source slows?
  5. Customer flow — Step by step: how does someone go from "interested" to "job completed and paid"?
  6. What systems exist? CRM? Calendar? Email list? QuickBooks? Stripe? Or is it all phone + memory?
  7. Tech maturity — Would the owners text a bot? Would they read a weekly SMS summary? What's their comfort level?
  8. Existing contacts — Do they have a list of past clients, referral partners (realtors, insurance adjusters) that's dormant?
Option B — Quantitative financial analysis (when the user provides an actual data export):
If the user can get a QuickBooks, bank, or Stripe export from the business, run a full financial analysis BEFORE the qualitative discovery. This replaces rough guesses with hard numbers and surfaces concrete cost-cutting opportunities. The findings directly inform agent design (minimum job size enforcement, travel surcharge calculation, pricing model validation, marketing timing).
Analysis framework:
  1. Parse the export, separate estimates from actual transactions, filter internal transfers from real expenses
  2. Revenue analysis (invoiced vs collected, top customers, concentration risk, seasonality)
  3. Expense breakdown by category (flag uncategorized, flag bank fees >3% of revenue)
  4. P&L and cumulative loss (has the business ever been profitable?)
  5. Travel cost attribution per job (match fuel/meals within ±2 days of invoices — flag jobs where travel >20% of revenue)
  6. Anomaly detection (largest expenses, recurring charges, miscategorized buckets)
  7. Generate 5-7 charts optimized for Telegram/mobile delivery
  8. Deliver: charts as images + full text report + concise written summary with actionable recommendations
See 
references/quickbooks-financial-analysis.md
for the full methodology: CSV parsing patterns, transaction type taxonomy, expense filtering code, travel attribution technique, chart specs, and common findings patterns in service businesses.
Key insight: Non-technical owners need interfaces that work via text message (SMS or Telegram). No dashboards. No logins. The agent sends, they read.
选项A——询问用户（无财务数据可用时）：
向对接企业主的用户询问以下问题，获取大致数据即可，概念开发无需精准数值：
  1. 运营主体？ 企业主、角色分工、职责划分（运营/营销/外勤）
  2. 业务量与定价——每月接单量、平均客单价、定价模式（按平方英尺？固定费率？分级定价？）
  3. 获客渠道——当前客户来源？大致占比（房产中介、谷歌搜索、转介绍、保险合作等）
  4. 营收渠道风险——80%的营收是否来自单一渠道？该渠道下滑时会发生什么？
  5. 客户流程——详细步骤：从「感兴趣」到「服务完成并付款」的全流程
  6. 现有系统？ 是否有CRM、日历、邮件列表、QuickBooks、Stripe？还是完全依赖电话+记忆？
  7. 技术接受度——企业主是否愿意给机器人发短信？是否会阅读每周短信汇总？他们的技术舒适区是什么？
  8. 存量联系人——是否有沉睡的老客户、转介绍合作伙伴（房产中介、保险理赔员）名单？
选项B——量化财务分析（用户能提供实际数据导出文件时）：
如果用户能获取企业的QuickBooks、银行或Stripe导出数据，在定性调研前先完成全面财务分析。这会用硬数据替代粗略猜测，发现具体的成本削减机会，分析结果将直接指导Agent设计（比如最低接单规模限制、差旅费附加费计算、定价模型验证、营销时机选择）。
分析框架：
  1. 解析导出文件，区分报价与实际交易，过滤内部转账与真实支出
  2. 营收分析（开票金额与到账金额对比、顶级客户、集中度风险、季节性波动）
  3. 费用分类明细（标记未分类项、标记占营收超3%的银行手续费）
  4. 损益表与累计亏损（企业是否盈利过？）
  5. 单趟服务差旅费归因（匹配发票前后±2天的燃油/餐费——标记差旅费占营收超20%的订单）
  6. 异常检测（大额支出、recurring charges、分类错误的项目）
  7. 生成5-7张适合Telegram/移动端展示的图表
  8. 交付：图表图片+完整文字报告+简洁的可行动建议摘要
完整方法请参考
references/quickbooks-financial-analysis.md
：CSV解析模式、交易类型分类、费用过滤代码、差旅费归因技术、图表规范，以及服务型企业的常见发现模式。
关键洞察： 非技术型企业主需要通过短信（SMS或Telegram）操作的界面。无需仪表盘，无需登录。Agent主动发送，他们只需查看。

Step 3: Agent System Design

步骤3：Agent系统设计

Map the business operations to a 6-stage agent loop:
Find Leads → Capture & Qualify → Estimate → Book → Bill → Report
    ↑                                                        |
    └────────────── Weekly Summary to Owners ←───────────────┘
Stage 1 — Find Leads:
  • Scrape listing sites (Zillow, MLS) for properties that signal "needs work": vacant, price drops, as-is, smoke damage, estate sales, foreclosures
  • Draft personalized outreach to listing agents
  • Import dormant contact lists → systematic re-engagement campaign
Stage 2 — Capture & Qualify:
  • Website chat agent → after-hours visitors don't bounce
  • Qualify: service type, square footage, location, insurance vs private, urgency
  • Text owners immediately with qualified lead info
Stage 3 — Estimate:
  • Auto-calculate from sqft × rate + modifiers (ceiling height, severity, travel distance, add-ons)
  • Give a range (order of magnitude), not a binding quote
  • Send formatted estimate for signature
Stage 4 — Book:
  • Check shared calendar availability
  • Schedule job → confirm with customer
  • Send field tech the job details
Stage 5 — Bill (Stripe):
  • Stripe invoice or Payment Link for deposit
  • Final invoice after completion
  • This is the "agent earns real money" moment — real invoice, real business
Stage 6 — Report:
  • Weekly cron job: text summary to owners
  • Leads contacted, responses, estimates sent, jobs booked, revenue collected
  • Pipeline status: what's hot, what's stalled
  • Owners read it on their phone. That's it.
将业务运营映射为6阶段Agent循环：
获客 → 线索捕获与资质审核 → 报价 → 预约 → 账单 → 报表
    ↑                                                        |
    └────────────── 每周汇总发送给企业主 ←───────────────┘
阶段1——获客：
  • 从房源网站（Zillow、MLS）抓取有「服务需求」信号的房产信息：空置、降价、按现状出售、烟熏损坏、遗产拍卖、止赎房产
  • 为房产中介撰写个性化outreach内容
  • 导入沉睡联系人名单 → 系统性再激活campaign
阶段2——线索捕获与资质审核：
  • 网站聊天Agent → 避免非工作时段访客流失
  • 资质审核：服务类型、房屋面积、位置、保险付费/私人付费、紧急程度
  • 立即通过短信向企业主发送合格线索信息
阶段3——报价：
  • 自动计算：面积×费率+调整项（天花板高度、问题严重程度、行程距离、附加服务）
  • 提供范围估值（数量级），而非绑定报价
  • 发送格式化报价供签署
阶段4——预约：
  • 检查共享日历可用性
  • 安排服务 → 与客户确认
  • 向外勤技术人员发送服务详情
阶段5——账单（Stripe）：
  • 通过Stripe发送发票或付款链接收取定金
  • 服务完成后发送最终发票
  • 这是「Agent创造真实收益」的时刻——真实发票，真实业务
阶段6——报表：
  • 每周定时任务：向企业主发送短信汇总
  • 包含联系的线索数、回复数、发送的报价数、已预约订单、到账营收
  • pipeline状态：跟进中、停滞的项目
  • 企业主在手机上查看即可，无需其他操作

Step 4: Stakeholder & Sponsor Mapping (If Applicable)

步骤4：利益相关方与赞助方映射（如适用）

If you're building this for a demo, pilot, or hackathon, map each agent stage to the stakeholder requirements that matter most:
StakeholderHow to Hit It
Agent platformThe agent IS the platform — cron, skills, subagents, text delivery. This is the commercial proof point.
PaymentsReal invoicing for real jobs. The "agent bills a customer" moment is a real invoice, not a test transaction.
ComputeAgent processes many leads cost-effectively. Keep cost-per-lead low enough that the economics work.
The story that lands: "I gave a real small business an AI employee. It found real leads, sent estimates, booked a $2,400 job, and collected the deposit. The owner saw it all in a text message."
A real business with a non-technical owner is the differentiator — proof that AI helps normal people, not just AI developers.
如果是为演示、试点或黑客松项目搭建，将每个Agent阶段与最关键的利益相关方需求对应：
利益相关方达成方式
Agent平台Agent本身就是平台——定时任务、skills、子Agent、短信交付。这是商业化证明点。
支付系统为真实订单开具真实发票。「Agent向客户开具账单」的时刻必须是真实发票，而非测试交易。
计算成本Agent高效处理大量线索，保持获客成本足够低，确保经济可行性。
打动评委的故事：「我给一家真实的小型企业配备了AI员工。它找到了真实线索，发送了报价，预约了一笔2400美元的订单，并收取了定金。企业主全程通过短信查看所有进展。」
拥有非技术型企业主的真实业务是差异化优势——证明AI能帮助普通人，而非仅服务AI开发者。

Step 5: Create the North Star Wiki Page

步骤5：创建North Star维基页面

Write a structured project page to the Obsidian vault at 
projects/<business-name>/index.md
. This is the cross-session anchor — the user can pull it up in any future session.
Required sections:
  1. North Star — one-sentence vision at the top (blockquote)
  2. Business Profile — table with owners, service area, avg job, lead sources, systems, website URL
  3. Current Flow — step-by-step how jobs work today
  4. Pain Points — bullet list of specific problems
  5. The Concept — the agent loop diagram + description per stage
  6. Hackathon Mapping — sponsor table (if applicable)
  7. Architecture & Tech Stack — infrastructure table, agent skills table, owner interface
  8. Pricing Model — table with rates, modifiers, TBDs
  9. Implementation Plan — phased with checkboxes (hackathon sprint + post-hackathon phases)
  10. Prerequisites Checklist — what the user needs to get from the business owners
  11. Success Metrics — hackathon, business (90-day), long-term
  12. Session Tracker — table with date, what was done, next steps
  13. Related Links — wikilinks + external URLs
Update the session tracker at the end of each session so the user can pick up where they left off.
在Obsidian知识库的
projects/<business-name>/index.md
中撰写结构化项目页面。这是跨会话的锚点——用户可在任何后续会话中查看。
必填章节：
  1. North Star — 顶部的一句话愿景（引用块）
  2. 企业概况 — 表格，包含企业主、服务区域、平均客单价、获客渠道、现有系统、网站URL
  3. 当前流程 — 现有服务流程的详细步骤
  4. 痛点 — 具体问题的项目符号列表
  5. 方案概念 — Agent循环图+各阶段描述
  6. 黑客松映射 — 赞助方表格（如适用）
  7. 架构与技术栈 — 基础设施表格、Agent skills表格、企业主界面
  8. 定价模型 — 表格，包含费率、调整项、待确定内容
  9. 实施计划 — 分阶段带复选框（黑客松冲刺阶段+赛后阶段）
  10. 前置条件清单 — 需要从企业主处获取的信息
  11. 成功指标 — 黑客松、业务（90天）、长期指标
  12. 会话跟踪 — 表格，包含日期、完成工作、下一步计划
  13. 相关链接 — 维基链接+外部URL
每次会话结束后更新会话跟踪，以便用户能从上次中断处继续。

Step 6: Infrastructure Setup

步骤6：基础设施搭建

  • Separate VPS + Hermes instance for the business — NOT on the user's personal instance
  • Stripe account — new, test mode for hackathon, real for production
  • Twilio or Telegram — for SMS/Telegram notifications to owners
  • Shared Google Calendar — for scheduling
  • Airtable or Google Sheets — lightweight CRM/pipeline tracker
  • Domain access — get registrar login from owners to rebuild website
  • Email integration — connect the owner's mailbox so the agent can read inbox, draft replies, and send approved emails. For Google Workspace accounts, use the Gmail API with OAuth2. For Microsoft 365 / Outlook.com accounts, use the 
    outlook-graph
    skill (Microsoft Graph API, NOT IMAP — Microsoft blocks basic auth IMAP). Device code flow for headless server auth. Dual-approval pattern: drafts save to the email provider's native Drafts folder → owner approves via Telegram or directly in the email client. See the 
    outlook-graph
    skill for M365 setup, or 
    construction-agent
    skill's 
    references/google-workspace-setup.md
    for Google Workspace setup.
  • 独立VPS + Hermes实例 用于该企业——不要部署在用户的个人实例上
  • Stripe账户 — 黑客松阶段用测试模式，生产环境用真实账户
  • Twilio或Telegram — 用于向企业主发送SMS/Telegram通知
  • 共享Google日历 — 用于预约调度
  • Airtable或Google Sheets — 轻量级CRM/pipeline跟踪工具
  • 域名权限 — 从企业主处获取注册商登录信息以重建网站
  • 邮件集成 — 连接企业主邮箱，使Agent能读取收件箱、撰写回复并发送经批准的邮件。对于Google Workspace账户，使用带OAuth2的Gmail API；对于Microsoft 365 / Outlook.com账户，使用
    outlook-graph
    技能（Microsoft Graph API，而非IMAP——微软已禁用基础认证IMAP）。采用设备码流实现无头服务器认证。双批准模式：草稿保存至邮件服务商的原生草稿文件夹→企业主通过Telegram或直接在邮件客户端批准。M365设置请参考
    outlook-graph
    技能，Google Workspace设置请参考
    construction-agent
    技能的
    references/google-workspace-setup.md
    。

Pitfalls

避坑指南

  1. Don't build dashboards for non-technical owners. They won't log in. Everything must work via text message.
  2. Don't assume the website works. Old WordPress sites built by contractors frequently have 404'd pages and stale content. Verify every nav link.
  3. Don't skip the pricing formula. The estimator tool is the "wow" moment for owners. Get exact rates, modifiers, and travel surcharges before building.
  4. Don't put the business agent on the user's personal Hermes instance. Separate VPS. The business needs its own instance that the user monitors remotely.
  5. Don't forget the dormant contact list. Most small service businesses have thousands of past contacts in phones/heads that have never been digitized. This is the fastest path to leads.
  6. Don't over-engineer the CRM. Start with Airtable or Google Sheets. Not Salesforce.
  7. Don't get owner names wrong — and don't auto-correct them either. Check spelling carefully at the start. A misspelled name in the wiki page propagates across sessions and into code. If the user corrects a name, fix it everywhere immediately — wiki, reference files, code, GitHub repo. This is a first-class error, not a typo. Critically: if a name is already documented, do NOT "fix" it to a more common spelling (e.g., the owner → the owner) based on your own assumption — only change it when the user explicitly tells you to. Auto-correcting a correct name to a wrong one is worse than the original typo because it compounds across every file and forces the user to correct you multiple times.
  8. Don't build for the echo chamber. If the hackathon concept only serves AI developers, it won't stand out. A real business with a non-technical owner is the differentiator.
  9. Don't use IMAP for Microsoft 365 email. Microsoft 365 blocks basic auth IMAP. Use the 
    outlook-graph
    skill (Microsoft Graph API + OAuth2 device code flow) instead. This works on headless servers (no browser redirect needed). The agent reads inbox, drafts replies to the native Drafts folder, and the owner approves via Telegram or directly in Outlook — dual path, no lock-in. For Google Workspace, use the Gmail API (see 
    construction-agent
    skill's 
    references/google-workspace-setup.md
    ).
  10. Don't auto-send emails without owner approval. Email is business communication, not a notification. Drafts go to the owner's Drafts folder; the agent never sends without explicit approval (via Telegram or Outlook). This is critical for trust — the owner must see every email before it goes out.
  11. Don't over-engineer for non-technical end-users. When the agent is for a non-technical end-user (business owner, family member), don't add Tailscale, tmux, or full tool access. The end-user interacts via Telegram only — they never SSH in. Tailscale and tmux are builder tools. Restrict the Telegram platform toolset to business-workflow tools only (file, vision, web, memory, skills, todo, clarify). No terminal, no code_execution, no cronjob, no delegation, no browser. Business workflows (briefings, email polling, pipelines) run via cron on the backend and deliver results to Telegram — the end-user doesn't trigger or manage them.
  12. Two interfaces, two roles. SSH is the builder channel (you — for updates, config, debugging). Telegram is the end-user channel (the business owner — for business workflows only). Design the deployment with this separation from the start. Don't expose admin capabilities (updates, restarts, config editing) through the Telegram gateway just because you can — it's bad practice and a security risk.
  1. 不要为非技术型企业主搭建仪表盘。他们不会登录。所有操作必须通过短信完成。
  2. 不要默认网站可用。承包商搭建的老旧WordPress网站经常存在404页面和过时内容。请验证每个导航链接。
  3. 不要跳过定价公式。报价工具是让企业主眼前一亮的关键。在搭建前获取准确的费率、调整项和差旅费附加费。
  4. 不要将企业Agent部署在用户的个人Hermes实例上。使用独立VPS。企业需要自己的实例，由用户远程监控。
  5. 不要忽略沉睡联系人名单。大多数小型服务企业的手机或脑海中存储着数千个未数字化的老联系人。这是最快的获客途径。
  6. 不要过度设计CRM。从Airtable或Google Sheets开始，不要用Salesforce。
  7. 不要写错企业主名字——也不要自动修正。一开始就仔细核对拼写。维基页面中的名字错误会在会话和代码中传播。如果用户纠正了名字，立即在所有地方修改——维基、参考文件、代码、GitHub仓库。这是严重错误，而非笔误。**关键：**如果名字已被记录，不要根据自己的假设「修正」为更常见的拼写（例如，将企业主的名字改成更通用的拼写）——只有当用户明确要求时才修改。将正确的名字自动改成错误的比原笔误更糟，因为它会在所有文件中扩散，迫使用户多次纠正你。
  8. 不要为AI从业者圈子设计方案。如果黑客松概念仅服务AI开发者，不会脱颖而出。拥有非技术型企业主的真实业务才是差异化优势。
  9. 不要为Microsoft 365邮件使用IMAP。Microsoft 365已禁用基础认证IMAP。请使用
    outlook-graph
    技能（Microsoft Graph API + OAuth2设备码流）替代。这适用于无头服务器（无需浏览器重定向）。Agent读取收件箱，将回复草稿保存至原生草稿文件夹，企业主通过Telegram或Outlook批准——双路径，无锁定。对于Google Workspace，使用Gmail API（参考
    construction-agent
    技能的
    references/google-workspace-setup.md
    ）。
  10. 不要未经企业主批准自动发送邮件。邮件是商务沟通，而非通知。草稿发送至企业主的草稿文件夹；Agent绝不会在未获得明确批准（通过Telegram或Outlook）的情况下发送邮件。这对建立信任至关重要——企业主必须在邮件发出前查看每一封。
  11. 不要为非技术终端用户过度设计。当Agent面向非技术终端用户（企业主、家庭成员）时，不要添加Tailscale、tmux或完整工具权限。终端用户仅通过Telegram交互——他们永远不会SSH登录。Tailscale和tmux是开发者工具。将Telegram平台工具集限制为仅业务工作流工具（文件、视觉、网页、记忆、skills、待办事项、澄清）。不要提供终端、代码执行、定时任务、委托、浏览器功能。业务工作流（简报、邮件轮询、pipeline）通过后端定时任务运行，并将结果发送至Telegram——终端用户无需触发或管理。
  12. 两个界面，两个角色。SSH是开发者渠道（你——用于更新、配置、调试）。Telegram是终端用户渠道（企业主——仅用于业务工作流）。从一开始就设计分离的部署方案。不要仅仅因为可以就通过Telegram网关暴露管理功能（更新、重启、配置编辑）——这是不良实践且存在安全风险。

Generalization

通用性

This methodology is designed to be a template. The same 6-stage agent loop applies to:
  • Plumbing — lead gen from home inspection reports, emergency after-hours capture, sqft-based or issue-based estimation
  • AC repair — seasonal outreach (pre-summer checkups), service tiers, recurring maintenance contracts
  • Lawn care — recurring billing (unlike one-shot services), neighborhood-based lead gen
  • Cleaning services — sqft-based estimation, realtor relationships
  • Construction — email→PM pipeline, project tracking, document routing (see 
    construction-agent
    skill)
  • Any field service — find leads, qualify, estimate, schedule, bill, report
本方法是一个模板。相同的6阶段Agent循环适用于：
  • 管道维修——从房屋检查报告获客、非工作时段紧急线索捕获、按面积或问题类型报价
  • 空调维修——季节性推广（夏季前检修）、服务分级、recurring维护合同
  • 草坪护理——recurring billing（不同于一次性服务）、基于社区的获客
  • 清洁服务——按面积报价、房产中介合作
  • 建筑施工——邮件→项目经理pipeline、项目跟踪、文档路由（参考
    construction-agent
    技能）
  • 任何外勤服务——获客、资质审核、报价、调度、账单、报表

Reference Files

参考文件

  • references/quickbooks-financial-analysis.md
    — Methodology for analyzing QuickBooks/bank financial exports: CSV parsing patterns, transaction type taxonomy, separating real expenses from internal transfers, travel cost attribution per job, chart generation for Telegram delivery, and common findings patterns in small service businesses.
This skill is a methodology guide. The skills in this repo are the concrete implementations of this pattern for specific business types. Use this skill to understand the approach, then use the other skills as reference implementations.
  • references/quickbooks-financial-analysis.md
    — 分析QuickBooks/银行财务导出文件的方法：CSV解析模式、交易类型分类、区分真实支出与内部转账、单趟服务差旅费归因、生成适合Telegram展示的图表，以及小型服务企业的常见发现模式。
本技能是方法指南。本仓库中的其他技能是针对特定业务类型的具体实现。使用本技能理解方法，然后参考其他技能的实现案例。

Related Skills in This Repo

仓库中的相关技能

  • lead-to-payment
     — the orchestration spine (the 6-stage loop in practice)
  • construction-agent
     — worked example: construction business with email→PM pipeline
  • estimator-engine
     — the estimation stage
  • crm-lite
     — the capture/qualification stage
  • stripe-payments
     — the billing stage
  • agent-cheatsheet-builder
     — the owner onboarding stage
  • financial-analysis
     — the reporting stage (CSV-based financial analysis)
  • lead-to-payment
     — 编排核心（6阶段循环的实际实现）
  • construction-agent
     — 实例：带邮件→项目经理pipeline的建筑企业
  • estimator-engine
     — 报价阶段实现
  • crm-lite
     — 线索捕获/资质审核阶段实现
  • stripe-payments
     — 账单阶段实现
  • agent-cheatsheet-builder
     — 企业主入职阶段实现
  • financial-analysis
     — 报表阶段实现（基于CSV的财务分析）