我们是XUPT_SEC1学生团队，团队成员来自西安邮电大学，分工明确：

张博远：负责整个项目定位与流程梳理

白子阳：负责前端与UI实现，完成ArkUI界面与交互细节

丁文杰：负责构建业务逻辑与数据层，实现会议审计、授权与导出

秦文廷：负责算法和制定安全策略，实现数据的敏感识别与脱敏

我们团队的宗旨是：先把方案提出来，再不断改进，前进总是大于原地踏步。

02

代码仓链接

https://openatom.tech/cangjiechallenge/d45e5bcde569dadcaf4fcc0524ac8f38

企业会议是敏感信息泄露的高发场景：客户名称、联系方式、报价策略、合同金额甚至账号密钥都可能被写进纪要。一旦纪要被随手转发或导出，就会快速扩散，带来商业与合规风险。我们调研发现，许多会议工具更偏向“记录与协作”，但缺少对内容风险的自动识别、外发的硬性约束与完整追溯，因此我们决定开发 SecureMeet Guardian（安全会议助手）这款纯仓颉软件，专注解决会后内容如何安全流转这一问题。

安全会议助手这款软件提供“检测→脱敏→管控→审计”的安全闭环。首先，系统支持实时敏感检测，覆盖手机号、身份证、邮箱、银行卡、IP、URL、域名、API密钥、客户名称等多类高频敏感要素；其次，软件集成了一键生成智能脱敏版本这一功能，按类型应用专属规则进行脱敏，在保护关键字段的同时尽量保留语义可读性；同时，当风险评分达到阈值时，启用导出管控：如禁止导出原文，但允许导出脱敏版等，兼顾安全与业务推进；最后软件通过审计日志记录关键操作与安全事件，满足合规审查与事后追责的安全标准。

项目基于仓颉语言开发，采用ArkUI实现鸿蒙原生界面。代码层以类型安全、模式匹配、空值约束与不可变数据为核心，减少状态分支遗漏和空指针风险；关键流程通过状态机建模（授权/撤回/审计/导出联动），将权限与meetingId绑定，避免UI伪状态。在性能方面，敏感识别使用预编译正则+扫描缓存与增量更新策略，配合热点词典进行分级索引，实现快速响应。架构采用3层架构：包括表现层（交互与状态驱动 UI）、服务层（审计/脱敏/授权/日志策略）、数据层（RDB +内存缓存+导出序列化）。同时提供离线降级与本地生成路径，保证在弱网场景下仍可完成审计与导出。

我们在开发过程中主要遇到三类问题：第一是实时性能压力，在进行敏感检测时如果每次全文重扫会带来明显卡顿，于是我们通过预编译规则与缓存机制减少重复计算，保证输入与检测体验流畅；第二是脱敏后的可读性，简单全打码会让纪要无法使用，我们针对不同敏感类型设计专属规则，在保证信息安全的同时兼顾可读性；第三是生态与接口差异，仓颉生态仍在完善和发展，导致接入与调试成本较高，我们抽象统一接口，同时把错误分层、日志打全，也为后期的升级打好基础。

这次备赛最大的体会是：比赛不是比较谁的功能更多，而是比较整个工程的完整性，即能不能在有限时间里做出完整闭环、并且现场讲得清楚，我们整理了三条对同类参赛者最有参考价值的经验：

开始做整个项目时不合适的分工导致我们变成了各做各的部分，后期在对接时产生了许多问题与分歧，我们认识到小组分工不是把任务“分开做”，而是把交付物拆成可以并行推进、且最后能无缝拼起来的模块。

Option空值安全必须显式处理：仓颉的Option类型强制处理空值，不能直接访问属性，必须用isSome()检查或match表达式；集合类型要区分可变性：Array不可变（不能append），ArrayList可变，@State状态变量必须用ArrayList。

我们的项目专注机密会议内容的安全合规性，而非构建大而全的会议系统，定位为"会议工具的安全增强层"，这使得我们的安全会议助手变成一个类似插件的功能软件，可以适配于各种已经成熟的会议软件。

感谢鸿蒙仓颉编程语言挑战赛主办方与承办方的支持，感谢仓颉语言团队与社区伙伴的交流帮助，感谢评委老师们的专业建议。我们将在仓颉领域探索，为鸿蒙仓颉生态贡献更多可落地的工程实践。