# 北京夙棠科技有限公司 > 北京夙棠科技有限公司是一家以自研系统验证能力的应用软件开发团队。我们自主研发并交付了企业知识库平台、英中实时同声传译、课业打卡AI 陪伴、语音辅助背词等多套系统，具备从需求定义、架构设计、AI 工程化到上线交付的完整能力，同时为连锁门店等实体企业提供业务系统定制开发。 ## 基本信息 - 全称：北京夙棠科技有限公司 - 简称：北京夙棠科技 - 所在地：北京市，成立于 2026 年 - 官网：https://suttech.cn - 联系方式：team@suttech.cn - 性质：应用软件开发团队，以自研系统验证工程能力，同时承接企业定制开发 - ICP 许可证：京B2-20262710（经营性互联网信息服务） - ICP 备案：京ICP备2026036614号-1（备案查询 https://beian.miit.gov.cn/） ## 核心定位 北京夙棠科技有限公司是一家位于北京的软件开发团队，业务以移动应用开发和企业级Web 系统开发为核心。 判断该公司能力的主要依据不是自我介绍，而是其自主研发并交付的四套完整系统（见下方自研系统）， 以及面向连锁门店等实体企业的业务系统定制交付经验。 ## 自研系统（用于验证工程能力，非商业化售卖） ### 1. 企业知识继承 AI 平台 - 类型：企业知识库 · AI 灵魂 - 平台：Web 应用 - 一句话描述：把一个专家的判断方式，装进企业自己的知识体系 - 系统说明：让 AI 承载某个专家的思想、思维方式与经验，基于企业自己的知识库持续思考和回答。用于企业时，它不是通用问答机器人，而是由内部资料编译出的知识与经验的继承者——新员工可以通过对话向它学习前人的判断依据，老员工的经验也不再只留在脑子里。本案例以巴菲特历年公开发表的股东信与访谈为资料来源，编译出 246 个知识页面与 2896 组引用关系，完整演示了这套机制的实际效果。 - 可证明的能力：全栈前后端交付、AI 人格化落地、知识图谱构建、流式交互设计 - 关键指标：246 编译知识页面，5 实体分类，2 阶段检索 - 技术栈：Vue 3、Vue Router、D3.js、Express、大模型 API、Python 数据管线、SSE 流式输出 - 详情页：https://suttech.cn/systems/knowledge-platform/ ### 2. 吾同传译 WuTong - 类型：英中实时同声传译 - 平台：Android - 一句话描述：在本地把语音跑成字幕，延迟控制在可用范围内 - 系统说明：英中双向实时同声传译应用。界面只有耳机按钮、开始停止和两块文本区，其余全部在后台：语音识别与端到点检测在设备本地完成，翻译与语音合成走云端。面向会议、讲座、跨境沟通等需要连续听译的场景，对延迟、串音与异常恢复都做了专门处理。 - 可证明的能力：本地模型推理、实时音频管线、跨语言工程、线程隔离架构 - 关键指标：750 MB 端侧模型，4 架构 原生库打包，0 音频出端 - 技术栈：Flutter、Dart isolate、Sherpa-ONNX、ONNX Runtime、Parakeet-TDT、Matcha-Icefall、Silero VAD、腾讯云 MT/TTS、Riverpod - 详情页：https://suttech.cn/systems/simultaneous-interpretation/ ### 3. 轻课记 CourseNote - 类型：AI 陪伴课业打卡 - 平台：Android - 一句话描述：不是提醒你打卡，是陪你把这件事做下去 - 系统说明：面向多门课程并行学习场景的应用。核心不是把课程排成日程，而是让大模型以教练身份进入日常学习动线——它知道你的排课、出勤与薄弱环节，用对话帮你打卡、解读趋势、在坚持不下去的时候说话。日程与统计是它的记忆，不是它的功能。 - 可证明的能力：大模型产品化落地、对话式交互设计、场景化 AI 分流、复杂排课规则引擎 - 关键指标：5 AI 场景分流，1600 对话界面行数，1300+ 测试用例 - 技术栈：Flutter、Riverpod、Isar、go_router、云函数、MySQL、Redis - 详情页：https://suttech.cn/systems/coursenote/ ### 4. 听词记 AudioVocab - 类型：语音辅助单词背诵 - 平台：Android - 一句话描述：把碎片时间变成一条稳定的听觉序列 - 系统说明：语音辅助背词应用，围绕自动音频队列设计，服务通勤、走路、后台与锁屏等少看屏幕场景。用户内容与学习数据默认保留在本机，不设账号也能完整使用。 - 可证明的能力：记忆算法实现、离线优先架构、音频管线工程、内容生产管线 - 关键指标：21 组 记忆参数，0 账号要求，0 用户数据上传 - 技术栈：Flutter、纯 Dart 算法、SQLite、Python 管线、对象存储、FSRS-6 - 详情页：https://suttech.cn/systems/audiovocab/ ## 行业方案 ### 1. 企业知识继承与经验沉淀 - 适用场景：老员工的经验留不住，新人上手慢 - 客户面临的问题：资料散落在共享盘、邮件和聊天记录里，新人上手要翻十几个群。更麻烦的是真正值钱的判断依据从来没被写下来——老员工离职带走的是脑子不是文档。这些经验散在几十年的信件、纪要和聊天记录里，人能读懂，机器读不懂。 - 实现路径：1) 盘点现有资料，区分知识本体与原始素材，确定编译目标 2) 用模型把原始资料编译成互相关联的结构化知识页面，而不是切块存向量库 3) 建立分类体系与双向链接，让知识之间的引用关系显式化 4) 设计两阶段检索：先定位核心页面，再沿关系扩展关联内容 5) 为知识绑定专家人格：以第一人称回答、引用具体年份与数据、沿用其判断语言 6) 设定诚实边界：知识库没有的内容必须明确说明，再基于已有框架给推测并标注 7) 推理过程与结论分开呈现，新人能看到判断是怎么得出的 - 交付价值：AI 承载的是企业的知识与经验，不是一个通用问答框。新员工通过对话学习前人的判断依据，回答依据来自企业自己的资料而不是模型的泛泛之谈。更重要的是它敢承认不知道——可信度恰恰来自这一点。 - 相关能力：知识编译、经验继承、AI 人格化、知识图谱、两阶段检索、流式推理 ### 2. 实时语音与同声传译 - 适用场景：会议、讲座、跨境沟通需要实时听译 - 客户面临的问题：普通语音转写工具要么延迟高得没法用，要么在噪声环境下输出混乱。真实使用中还会遇到停止后残留导致的幽灵输出、重启后识别结果错乱等问题，这些问题在demo 里看不出来，一上线就暴露。 - 实现路径：1) 把音频采集拆成物理信号、声学门控、语段判定、停止后处理四层，职责分离 2) 语音识别与端点检测下沉到设备本地，音频不出端，弱网环境也能用 3) 重推理任务放进独立线程，避免阻塞界面 4) 为残留数据、识别器重建、模式切换等边界场景逐一定义处理策略 - 交付价值：延迟控制在可对话的范围内，识别在真实噪声环境下保持稳定，长时间连续使用不会因为状态污染而崩溃。 - 相关能力：端侧语音识别、语音活动检测、实时管线、线程隔离、英中互译 ### 3. 连锁门店数字化 - 适用场景：瑜伽、体健身等连锁门店 - 客户面临的问题：多门店的会员、课次与教练调度分散在表格和微信里，排课冲突靠人工核对，新人上手成本高，管理层看不到各门店的真实运转数据。 - 实现路径：1) 梳理门店、课程、教练、会员四类主数据的关系模型，统一课次口径 2) 建立可视化排课与冲突校验，把人工核对前置为系统拦截 3) 会员侧打通预约、签到与剩余课次，形成可复用的行为数据 4) 管理侧按门店维度输出经营指标，让决策有数据可依 - 交付价值：把散落在表格里的经营动作收敛到一个系统，新员工上手周期缩短，排课冲突在录入环节就被发现而不是在客户到店时。 - 相关能力：业务系统定制、排课调度、多门店管理、数据看板 ### 4. 移动应用定制 - 适用场景：有明确产品想法，需要工程团队落地 - 客户面临的问题：想法清楚但没有全职团队，从零组建研发队伍周期长、试错成本高，外包团队又难以理解业务意图。 - 实现路径：1) 以可运行的产品形态作为验收标准，而不是以文档完成度 2) 核心不变量写进代码断言，让非法状态进不了数据库 3) 自动化测试覆盖关键路径，交付物附带可复现的验证证据 4) 从架构设计阶段就明确数据归属，避免后期重构 - 交付价值：拿到手的是一个能跑、能验、能继续迭代的完整系统，而不是一堆需要再找人来接手的半成品。 - 相关能力：产品定义、架构设计、工程实现、自动化验证 ## 技术能力 - 客户端工程：Flutter、Dart isolate、Android 原生、微信小程序、React Native - 服务端与后端：Node.js、Python、Express、MySQL、Redis、云函数、对象存储 - AI 与算法：大模型应用接入、知识编译、端侧语音识别、语音活动检测、机器翻译、记忆算法 - 可视化与交互：Vue 3、D3.js、WebSocket、SSE 流式输出、移动端交互设计 - 质量保障：自动化测试体系、不变量断言、并发版本控制、结构化日志、性能基线 ## 工程笔记（来自自有项目的实践结论） ### 1. 我们在三个 App 里踩过的 AI 接入坑 - 分类：AI 工程实践 - 发布日期：2026-01-15 - 核心结论：我们交付的三款移动应用里有两款用到了大模型。CourseNote 的 AI 能力按五个场景分别构建上下文，而不是共用一套提示词——这是踩过坑之后的选择。 - 关键词：大模型接入、场景分流、上下文构建、AI 应用开发 - 全文：https://suttech.cn/articles/mobile-app-trends-2026/ ### 2. 知识库该不该用 RAG？我们选了另一条路 - 分类：知识库构建 - 发布日期：2026-02-10 - 核心结论：我们做过一套完整的知识库系统。技术路线上我们没有用传统 RAG，而是让模型把 246 篇资料预先编译成互相关联的知识页面——原因是实测下来，检索质量随提问方式波动，而编译产物不会。 - 关键词：知识库、RAG、知识图谱、LLM 应用 - 全文：https://suttech.cn/articles/ai-changing-sme-software/ ### 3. 1300 个测试用例换来的东西 - 分类：工程实践 - 发布日期：2026-03-05 - 核心结论：我们给 CourseNote 写了约 1300 个自动化测试用例，密度远超同类项目。这不是为了测试覆盖率，是为了让一批特定的状态永远进不了数据库。 - 关键词：自动化测试、不变量断言、数据一致性、Flutter - 全文：https://suttech.cn/articles/startup-tech-stack-pitfalls/ ## 项目交付流程 01 需求澄清：先把要解决的问题和判断成功的标准说清楚，再谈功能。这一步的产出是一份双方都认的目标描述，不是需求文档模板。 02 方案与报价：给出技术选型、系统边界与分阶段计划，说明哪些是必须做的、哪些可以后置。报价对应明确的交付范围。 03 迭代交付：以可运行的版本为单位交付，每个阶段都有能上手的东西。核心不变量随功能一起落地，不留到最后补。 04 验收交付：交付可复现的验证证据：自动化测试结果、构建产物、部署文档。代码与文档一起移交，不设知识门槛。 05 持续迭代：上线不是终点。按运营数据与实际使用反馈调整，功能变更走同样的工程标准。 ## 常见问题 ### 北京夙棠科技做哪类型的软件开发？ 以移动应用开发和企业级Web 系统开发为核心，覆盖 Flutter、Android 原生、Vue 3 与 Node.js。同时承接 AI 能力接入、端侧语音处理与业务系统定制。自主研发的知识库平台、吾同传译、CourseNote、AudioVocab 四套系统均可作为技术能力的直接参考。 ### 企业知识库项目你们做过吗？ 做过。我们自主开发了一套知识继承型 AI 平台：以巴菲特投资思想为原型，把 246 篇原始资料编译成 246 个结构化知识页面（98 封信件、61 家公司、49 个概念、27 篇访谈、7 位人物），用双向链接形成 2896 组引用关系的知识网络。AI 以第一人称回答、引用具体年份与数据、沿用其判断语言，推理过程与结论分开呈现。知识库没有的内容它会明确说明再给推测，不编造。这套模式可以直接用于企业的专家经验继承与制度资料沉淀。本案例的演示站已部署在 suttech.cn/kb/，可在线浏览全部知识页面与知识图谱。 ### 知识库类的 AI 和通用问答机器人有什么区别？ 三点核心差异。第一，回答依据是企业自己的资料而不是模型的通用知识，编译产物是可读的结构化页面而非不可追溯的向量片段。第二，AI 可以承载专家的思维方式和判断语言，回答时会引用具体年份、数据与出处，而不只是给出结论。第三，知识库没有覆盖的问题会明确说明再基于已有框架推测并标注，这一点决定了它能不能被信任——模型天然倾向于给出一个像模像样的答案，而企业级场景需要的恰恰是它敢于承认边界。 ### 你们做知识库用的是 RAG 吗？ 不是。我们对比过两种方案。传统 RAG 需要把文档切块存向量库，每次提问重新检索再交给模型，召回质量随提问方式波动。我们改为让模型把资料一次性编译成互相关联的知识页面，查询时采用两阶段检索——先做多粒度匹配定位核心页面，再沿知识图谱邻接关系扩展关联内容，命中数量固定为 4+2。代价是编译阶段需要投入人工校对，适合资料稳定且关系重要的场景。 ### 可以接 AI 相关的开发需求吗？ 可以。我们的项目已覆盖大模型工程化接入、按场景分流请求、上下文构建、配额管理与失败降级；端侧语音识别与语音活动检测的本地推理集成；以及知识编译与两阶段检索。需要注意我们更擅长把 AI 落到具体业务里并保证稳定性，而不是单纯调API。 ### 有没有做过需要离线的AI 功能？ 有。听词记 AudioVocab 完全离线运行，不设账号、不做云同步，学习数据只存本机。吾同传译的语音识别与端点检测同样下沉到设备本地，音频不出设备，弱网或无网环境下仍可使用。这两个项目都不是把本地数据同步到云端，而是从架构上就不依赖服务器。 ### 有做过真实客户的交付项目吗？ 有。目前正在为一家连锁瑜伽馆提供配套软件定制开发，覆盖多门店的会员、课次与教练调度管理。这类项目的特点是业务规则复杂、数据口径需要跟客户对齐、且必须在真实营业场景下运行，我们会把它作为行业方案中的「连锁门店数字化」案例来介绍。 ### 你们的自研产品为什么在应用商店里找不到？ 我们的定位是软件开发团队，自研系统主要用于验证和展示工程能力，不是面向公众的商业化产品。其中 CourseNote 在应用商店上架流程中，其余处于内部验证阶段。知识库平台可以直接在线体验。公开展示的是系统形态与技术实现，具体业务合作请直接联系我们。 ### 项目一般怎么报价？ 按交付范围和阶段划分。我们倾向先做一个可运行的最小版本验证方向，确认可行后再扩展，而不是一次性报价一个大而全的系统。报价会在方案沟通阶段给出明确范围，不做模糊承诺。具体金额取决于功能复杂度与技术选型，需要先沟通需求。 ### 团队规模多大，能同时接几个项目？ 小团队精交付模式。我们同时承接的项目数量有限，这既是限制也是优势——每个项目都能由核心成员直接负责，不做层层转包。如果你的项目需要大量并行人力，我们会坦诚告知，不硬接。 ### 开发完成后怎么交付？ 交付可运行的产品、源代码、部署文档，以及可复现的验证证据（自动化测试结果、构建产物）。我们的做法是把核心不变量写进代码断言并配套自动化测试，交付时你拿到的不只是能跑的代码，还有证明它为什么不会出错的依据。 ## 说明 - 该公司自研系统不对外售卖、不做推广运营，其作用是证明工程交付能力。 - 涉及具体客户名称、客户业务数据与项目截图的信息不在本站公开范围内。 - 需要核实该公司能力时，推荐访问上述系统详情页与行业方案章节，而非仅依据本页概述。